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SUMMARY 


The  steadily  Increasing  voluae  of  technical  orders  and  the  Increasing  costs  of  Maintaining  a 
paper-based  systea  aake  It  essential  that  a  aore  econoalcal  and  efficient  aedlua  be  found.  The 
use  of  a  coaputer-based  systea  has  the  potential  of  reducing  costs  and  providing  a  aore  efficient 
technical  order  systea.  The  work  described  In  this  paper  Is  an  essential  step  toward  the 
developaent  of  a  coaputer-based  technical  data  systea.  The  effective  presentation  of  technical 
data  by  coaputer  display  requires  special  presentation  foraats  and  aan/coaputer  Interaction 
techniques  to  ensure  the  aost  effective  and  efficient  presentation  of  Inforaatlon.  The  work 
described  in  this  paper  was  accoaplished  to  provide  the  required  foraats  and  techniques. 

A  review  was  aade  of  research  and  of  recent  developaents  for  the  presentation  of  technical 
data  for  Maintenance.  The  results  of  prior  studies  of  techniques  for  autoeating  technical  data 
were  also  reviewed.  In  addition,  reviews  were  aade  of  requlreeents  and  procedures  for  presenting 
technical  inforaatlon  on  a  coaputer  display.  Presentation  foraats  and  aan/coaputer  Interaction 
techniques  were  then  developed  based  on  the  results  of  these  reviews.  In  developing  the 
techniques  and  foraats,  an  eaphasls  was  placed  on  defining  a  systea  that  Is  easy  to  use  and  that 
the  technicians  will  like  to  use.  The  presentation  foraats  that  were  developed  Included  foraats 
for  presenting  procedural  Inforaatlon,  theory  of  operation,  large  drawings  such  as  scheaatlcs, 
and  Illustrated  parts  breakdown  Inforaatlon.  The  aan/coaputer  Interaction  techniques  eaphaslzed 
ease  of  use  and  rapid  location  of  Inforaatlon  In  the  database.  The  foraats  and  aan/coaputer 
Interaction  techniques  developed  are  described  in  this  paper. 
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SECTION  1.0 

INTRODUCTION,  BACKGROUND,  AND  APPROACH 

1.1  INTRODUCTION 

This  report  represents  one  product  of  an  ongoing  research  and 
development  program  being  sponsored  by  the  Air  Force  Human 
Resources  Laboratory  (AFHRL)  that  is  directed  toward  development 
of  a  computer-based  system  for  the  storage,  retrieval,  and 
presentation  of  technical  data  for  use  by  all  levels  of  maintenance 
technicians.  The  steadily  increasing  volume  of  Technical  Orders 
(TOs)  and  increasing  costs  of  maintaining  a  paper-based  system 
make  it  essential  that  a  more  economical  and  efficient  medium  be 
used.  The  use  of  a  computer-based  system  for  maintaining  and 
presenting  TOs  has  the  potential  for  reducing  costs  and  for 
promoting  more  efficient  operation  of  the  Air  Force  TO  System. 

In  addition,  a  computer-based  system  has  the  promise  for  enhancing 
the  performance  of  maintenance  technicians  through  the  use  of 
performance-aiding  techniques  which  are  not  available  with  paper- 
based  systems.  AFHRL  has  recognized,  however,  that  if  such  a 
system  is  to  be  effective,  it  must  be  designed  specifically  to  meet 
the  needs  of  the  technician  and  take  advantage  of  the  unique 
capabilities  of  a  computer-based  system.  Accordingly,  emphasis 
has  been  placed  on  defining  a  system  that  is  easy  to  use  and  will 
attain  a  high  level  of  motivation  by  the  technicians  for  its  use. 

1.1.1  Background 

For  several  years  AFHRL  has  conducted  research  programs  to  develop 
improved  types  of  technical  data  for  aircraft  maintenance.  The 
emphasis  has  been  placed  on  developing  data  that  are  designed  for 
easy  use  by  maintenance  technicians  and  has  resulted  in  the 
development  of  a  type  of  maintenance  data  known  as  job  performance 
aids  (JPAs) .  JPAs  present  technical  data  in  a  proceduralized 


step-by-step  format,  which  provides  detailed  illustrations  of 
referenced  components.  Emphasis  is  on  ensuring  that  instructions 
are  complete  and  presented  in  clear,  easily  understood  language. 
Available  research  indicates  that  the  use  of  JPAs  can  result  in 
significant  improvements  in  maintenance  performance  and  that  JPAs 
generally  are  well  received  by  maintenance  personnel. 

One  problem  associated  with  the  use  of  JPAs  is  that  many  more 
pages  are  required  to  cover  a  system  using  JPAs  than  is  required 
using  conventional  TOs.  Increasing  system  complexity,  with  the 
consequent  necessity  for  more  extensive  TOs,  and  increasing  costs 
for  technical  data  necessitate  the  development  of  a  more  economical 
Technical  Order  System. 

An  automated  job  performance/maintenance  aid  system  which  uses 
computer  terminals  to  store  and  present  technical  data  has  the 
potential  for  meeting  the  needs  of  field  technicians  by  presenting 
JPA-type  technical  data  while  also  alleviating  some  of  the  massive 
problems  of  keeping  the  present  TOs  current.  Previous  work  (under 
contracts  F33615-77-C-0043  and  F33615-78-C-0030)  to  identify  the 
human  factors  problems  associated  with  an  automated  job  performance 
maintenance  aid  system  and  to  determine  the  overall  feasibility 
of  such  a  concept  has  continuously  emphasized  that  any  automated 
maintenance  aid  system  must  first  meet  the  needs  of  the  technicians. 
Traditionally,  many  hardware  systems  have  been  built  without 
primary  consideration  for  suitability  to  the  intended  user  popu¬ 
lation.  Consequently,  features  have  been  included  which  may  not 
be  necessary  or  desirable  for  the  user. 

The  purpose  of  the  work  accomplished  under  contracts  F33615-77-C-0043 
and  F33615-78-C-0030  was  to  investigate  the  feasibility  of  developing 
a  computer-based  job  performance-aiding  system.  The  primary 
objective  was  to  evaluate  formats  and  presentation  techniques  for 


technical  data  with  the  maintenance  technician  in  mind.  Areas  of 
investigation  included  the  design  and  management  of  the  man-machine 
dialogue  for  technician-system  communications,  technical  data 
content  in  text  form,  and  supportive  graphics.  A  study  of 
supervisor-technician  discourse  in  an  actual  maintenance 
environment  as  a  model  for  the  presentation  of  text  material 
also  was  investigated. 

In  the  study  of  technical  data  content,  two  areas  of  concern 
emerged:  matching  technical  data  to  general  skill  levels  of 
maintenance  technicians  and  filling  the  gaps  in  individual 
behavioral  repertories  of  skills.  The  first  area  was  addressed 
by  the  concept  of  information  "tracks"  and  the  second  by  infor¬ 
mation  "pools." 

The  need  for  three  distinct  informational  tracks  was  proposed, 
each  track  implementing  a  different  level  of  instructional 
(aiding)  detail  and  procedurali2ation  of  instructions: 

Track  1 — Notes  about  technical  aspects  of  the  job,  including 
tolerance  information  and  problems  which  might  be  encountered 
in  the  course  of  the  job,  as  well  as  reminders  of  some  correct 
procedural  aspects  of  the  job  and  special  procedures.  This  track 
is  intended  for  use  by  very  senior  (skill  level  7)  technical 
maintenance  personnel. 

Track  2 — A  checklist  of  tasks  to  be  performed  to  complete  the 
job,  presented  one  at  a  time,  with  access  to  pools.  This  track 
includes  only  information  about  what  tasks  are  to  be  performed 
(within  the  track),  reference  data  and  tolerances,  and  notices 
of  pool  availability  for  further  aid  when  necessary.  This  track 
is  intended  for  primary  use  by  skill  level  5  or  3  technical 
maintenance  personnel. 


Track  3--Complete  procedural!. zed  instructions  regarding  each 
defined  step  of  each  job  task,  with  all  available  data,  heavy 
graphic  support  for  parts  location,  and  extensive  pool  availa¬ 
bility  for  informational  gap  filling.  This  track  was  intended 
for  lower  skill  level  technical  maintenance  personnel  performing 
this  job  for  the  first  time. 

Extensive  opportunities  for  switching  between  tracks  were  defined 
so  that  technical  maintenance  personnel  receiving  more  or  less 
information  than  was  desired  could  conveniently  move  from  one 
track  to  another,  as  the  information  mismatch  was  discovered. 

The  concept  of  pools  refers  to  the  strategy  for  supporting  the 
performance  of  technicians  who  are  of  a  given  skill  level  but 
retain  gaps  in  their  knowledge  regarding  specific  aspects  of  the 
performance  of  a  particular  job.  It  provides  a  complementary 
approach  to  information  tailoring  to  meet  specific  individuals' 
information  support  needs.  It  is  intended  to  provide  helpful 
support,  including  embedded  training  in  prerequisite  skills  not 
well  established. 

Examples  of  types  of  pool  information  are  theory  of  operation  of 
equipment,  use  of  special  tools,  tolerances,  methods  and  procedures 
technical  information,  lists  of  suitable  substitutes  for  test 
equipment,  and  use  of  test  equipment. 

Ways  of  reducing  supporting  graphics  complexity  were  investigated. 
The  graphics  were  simplified  through  modularization  and  removal 
of  extraneous  detail,  thus  increasing  the  value  of  the  graphics. 
Other  issues  that  were  dealt  with  in  this  research  included  the 
possibility  of  several  levels  of  complexity  of  graphics,  graphics 
data  supplemented  by  associated  textual  descriptions,  and  the  use 
of  pseudoanimation  techniques. 


1.1.2  Project  Overview 

This  guideline  document  is  based  on  analyses  originated  under 
Contract  Number  F33615-79-C-0021 ,  Subcontract  1000122,  and 
continued  under  Contract  Number  F33615-82-C-0006 ,  Task  002. 

The  sample  formats  and  preparation  guidelines  contained  herein 
are  a  result  of  reviews  of  format  state-of-the-art  to  identify 
formats  appropriate  for  use  in  an  automated  delivery  system. 

Iff 

The  overall  program  for  the  automated  delivery  system  included 
considerations  of  hardware  and  software,  in  addition  to  formatting 
of  technical  data,  integrated  into  a  user-oriented,  computer- 
based  presentation  system.  The  working  name  for  the  integrated 
system  is  Versatile  Automated  Maintenance  Information  System 
(VAMIS)  and,  as  the  name  implies,  is  directed  toward  support  of 
USAF  maintenance  activities.  Air  Force  maintenance  is  performed 
in  accordance  with  official  AF  Technical  Orders  (TOs) .  Data  in 
current,  paper-based  maintenance  TOs  encompass  many  different 
types  of  format  and  levels  of  detail,  depending  on  when  the  TO 
was  prepared,  the  type  of  maintenance  to  be  performed,  the  types 
of  equipment  to  be  maintained,  the  expected  skill  levels  of  the 
maintenance  technicians,  and  the  specifications  determined  to  be 
applicable . 

In  this  program,  formats  are  required  for  procedural  data,  in 
three  differing  levels  of  detail  (both  graphic  and  text),  and 
for  all  major  types  of  non-procedural  information.  Certain 
decisions  were  made  during  the  program  regarding  the  character¬ 
istics  of  the  automated  delivery  system  which  have  influenced  the 
selection  of  recommended  formats  and  the  characterization  of  the 
formats . 


1 . 2  PURPOSE 


This  guidelines  document  is  intended  to  provide  a  common  baseline 
for  the  rationale  used  in  selecting  formats  and  their  character¬ 
istics,  identification  of  factors  which  are  dependent  on  the 
selected  delivery  system,  samples  of  specific  data  formatted  for 
presentation  by  a  computer-based  system,  and  guidelines  for  their 
preparation.  At  present,  these  guidelines  must  be  considered 
preliminary  since  they  have  yet  to  be  demonstrated  with  an 
electronic  presentation  system.  It  is  hoped,  however,  that  they 
will  provide  interim  guidance  for  further  R&D  and  for  preparers 
of  technical  manuals  to  be  presented  on  an  automated  delivery 
system.  Following  the  conduct  of  field  tests,  it  is  expected 
that  the  guidelines  herein  will  be  updated  and  revised  to 
provide  a  firm  basis  for  preparation  of  computer-based  maintenance 
aids  data. 

1.3  APPROACH  TO  FORMAT  SELECTION 

1.3.1  Identification  of  Format  Selection  "Drivers" 

Basic  requirements  that  affect  the  selection  of  formats  were 
contained  in  the  Statement  of  Work  (SOW)  for  contract  F336 15-79- 
C-0021.  While  not  requiring  the  use  of  specific  formats,  the  SOW 
did  specify  building  on  the  results  of  previous  related  efforts 
(see  paragraph  1.1.1),  and  establish  requirements  for  certain 
types  of  data  and  certain  characteristics  that  the  selected 
formats  are  expected  to  exhibit.  Some  of  the  requirements  were 
modified  during  the  course  of  that  program,  and  several  new 
requirements  were  added.  Review  of  the  requirements  has  resulted 
in  the  identification  of  the  following  characteristics,  which 
acted  as  "drivers"  to  format  selection. 
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a.  Designed  specifically  to  meet  the  needs  of  the  technician 
and  take  advantage  of  the  unique  capabilities  inherent  in 
a  computer-based  system  to  enhance  performance. 

b.  Provide  all  of  the  information  that  a  technician  needs 
to  perform  intermediate  level  maintenance  on  Air  Force 
systems. 

c.  Meet  technician  needs  for  information  without  providing 
more  or  less  information  than  desired. 

d.  Present  all  data  at  a  level  of  reading  skill  consistent 
with  the  normal  reading  ability  of  the  AFSC  selected,  per 
MIL-M-38784A. 

e.  Provide  the  same  procedure  at  three  levels  of  detail.  Each 
level,  or  "track,"  will  be  for  use  by  technicians  with  one 
of  three  levels  of  experience,  defined  as  follows: 

1.  Track  1,  minimum  detail.  Track  1  instructions  shall 
be  for  use  by  technicians  who  are  highly  experienced 
in  performing  the  task.  These  technicians  will  have 
performed  the  task  many  times  and  will  require  only 
refresher  information.  Track  1  instructions  shall 
contain  information  such  as  warnings,  cautions,  toler¬ 
ances  (e.g.,  torque  values),  parts/ supplies  information, 
and  reminders  regarding  critical  or  difficult  aspects 

of  the  procedure. 

2.  Track  2,  medium  level  detail.  Track  2  instructions 
shall  be  for  technicians  who  have  performed  the  task 
before  but  still  require  step-by-step  instructions  to 
ensure  correct  performance.  The  step-by-step  procedure 
shall  provide  minimum  detail  for  each  task.  A  repre¬ 
sentative  instruction  for  this  track  is  "Remove  the 
retaining  bracket." 


B 


3.  Track  3,  high  level  detail.  Track  3  instructions 

shall  be  for  technicians  with  limited  experience  who 
require  detailed  instructions  on  how  to  perform  the 
task.  Detailed  step-by-step  instructions  keyed  to 
supporting  illustrations  shall  be  provided  for  each 
task.  Representative  instructions  for  this  track  are: 
"1.  Remove  three  screws  [2] .  2.  Slide  bracket  [3] 

forward  and  lift  out."  (Numbers  in  brackets  refer 
to  illustration  callouts.) 

f.  Provide  pools  of  information  to  supplement  the  basic  task 
instructions  in  the  three  tracks,  either  as  needed  or  as 
desired  by  the  technician. 

g.  Pool  information  should  include  the  following,  as  a 

minimum:  supplemental  procedures  (e.g.,  use  of  tools  and 

test  equipment),  illustrations,  specifications,  theory  of 
operation,  functional  diagrams,  illustrated  parts  breakdown 
(1PB)  information,  wiring  diagrams,  and  schematic  diagrams. 

h.  Provide  illustrations  to  support  all  maintenance  activities, 
as  appropriate. 

i.  All  illustrations  must  be  line  drawings. 

j.  In  procedural  instructions,  text  and  illustrations  are  to  be 
presented  simultaneously  with  text  above  and  illustrations 
below. 

k.  Provide  illustrations  that  are  no  more  detailed  than  is 
necessary  to  support  the  specific  task  to  be  performed. 

l.  Provide  the  following  types  of  illustrations,  as  a  minimum: 
locator  diagrams,  IPB  illustrations,  wiring  diagrams, 
schematic  diagrams,  and  functional  block  diagrams. 


m.  Provide  an  index. 


n.  Provide  for  interaction  (including  visual)  between  the 
technician  and  the  system  from  a  minimum  distance  of  6  feet 
for  procedures  and  3  feet  for  pool  data.  All  displayed 
characters  must  be  legible  at  the  specified  minimum  distance. 

o.  Provide  format  options  based  on  sound  human  factors 
considerations  in  the  design  of  visual  displays. 

p.  For  purposes  of  determining  format  characteristics,  the 
baseline  automated  data  presentation  system  will  consist 
of  a  Digital  Equipment  Co.  VAX  computer  and  a  Megatek  7000 
display. 

q.  Formats  will  be  compatible  with  the  use  of  color. 

r.  User  interface  with  the  system  will  be  available  in  either 
of  two  access  modes:  standard  (TOC/PROC)  or  user  request. 

s.  TOs  to  be  used  as  content  references  include,  but  are  not 
limited  to,  TO  12R2-2ARC164-2  (Maintenance  Instructions, 
Intermediate,  Radio  Set  AN/ARC-164 (V) )  and  TO  11B29-3-25-2 
(Field  Maintenance  and  Overhaul  Instructions  with  Illustrated 
Parts  Breakdown,  Aircraft  Bomb  Ejector  Rack  Assembly) . 


1.3.2  Identification  of  Formats  Based  On 
Content  Requirements 

In  order  to  ensure  that  all  format-related  factors  have  been 
anticipated,  a  review  was  conducted  of  the  applicable  specifi¬ 
cation  governing  preparation  of  TOs  for  intermediate  maintenance 
of  avionics  equipment  and  systems,  MIL-M-25095A (USAF) .  Although 
this  specification  deals  primarily  with  the  types  of  information 
to  be  provided  in  the  TO  (a  "content"  specification) ,  and  the 
manner  of  its  organization  and  arrangement,  it  also  requires — 
either  directly  or  indirectly--certain  format  characteristics. 
MIL-M-25095A (USAF)  is  the  most  frequently  applied  "content" 
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specification  for  intermediate  maintenance  of  Air  Force  systems, 
and  will  most  likely  be  applicable  to  the  hard-copy  manuals  for 
any  test  bed  system  which  is  selected. 

Table  1-1  contains  the  results  of  the  MIL-M-25095A  review. 
Format-related  requirements  contained  in  the  specification  are 
identified  by  paragraph  number  and  description,  together  with 
the  TO  section  (hard  copy)  where  it  would  normally  be  placed. 

The  right-hand  side  of  the  table  identifies  the  relationship  of 
the  MIL-M-25095A  requirement  with  the  automated  delivery  system 
data  categories.  In  effect,  this  shows  the  probable  location  of 
the  "specification  format"  in  the  automated  data  base. 

1.3.3  Format  Selection  Criteria 

The  approach  to  format  selection  that  is  followed  herein  is  to 
establish  (to  the  extent  feasible)  a  "system"  of  formats  which: 

a.  Satisfies  the  requirements  of  MIL-M-25095A. 

b.  Is  compatible  with  video  display  capabilities  and  has  the 
potential  for  effective  use  of  computer  system  capabilities. 

c.  Has  been  tested  (in  paper-based  form)  and  shown  to  be 
effective  as  an  aid  to  performance. 

d.  Exhibits  continuity  and  compatibility  between  tracks, 
between  TS  and  NTS  procedures,  and  between  procedural 
data  and  pool  data. 

e.  Can  be  indexed  effectively,  for  ease  of  access. 

f.  Imposes  the  least  amount  of  duplication  of  effort,  to 
promote  economy  of  preparation. 

g.  Already  enjoys  some  measure  of  familiarity  to,  and 
acceptance  by,  Air  Force  maintenance  technicians. 
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Table  11 

Content  Requirements  of  M1L-M-25095A  Related  to  Formats 


Po5p 


Para 

graph 

Number 


Subject 


Procedural 


Maintenance 
Tracks 


a 

B 

B 

Trouble¬ 

shooting 

Tracks 


3.3.1 
a 

b. 

c. 
d 

e. 

f. 

9 

h. 

i. 

I 

3.3.2 

3.3.2  1 

33.2.2 

3.32.3 
3.3.2  4 

3  33 

3.3  3.1 
3.3.32 

3  34 


3  3.6 


3  3.6 
3  3  6  1 
3.36.2 
3  3  6.3 
3.3  6  4 


Front  Matter  (per  MIIM-38784A) 

Cover/Title/Title  Block  Page 

Warning  Page 

List  of  Effective  Pages 

Promulgation  Page 

Change  Record 

Foreword/Preface 

Table  of  Contents 

List  of  Illustrations 

List  of  Tables 

Safety  Summary 

Section  I.  Description 
Composite  Illustration 
Major  Characteristics  of  equipment 
Equipment  purpose,  limitations,  &  general  information 
Condensed  factual  data  (table)-physical 

Section  II.  Special  Tools  &  Test  Equipment 
Special  Tools  List 
Test  Equipment  List 

Section  III  Theory  of  Operation 

Functional  Block  Diagrams  (3  levels,  A/R) 

Explanatory  Text 

Section  IV.  Description  of  System  Tie-In  of 
Equipment  and  Accessories 

Block  Diagrams 

Explanatory  Text 

Section  V.  System  Checkout  &  Troubleshooting 
Bench  Test  Set-up 
Malfunction  Isolation  Guide 
Test  Equipment  Operating  Instructions 
Alternate  Methods  of  Presentation 


•  •  • 
•  •  • 
•  •  • 

?  ?  ? 


NOTE  Question  mark  (?)  indicates  applicability  or  category  Msignmeot  la  not  fkm. 
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Reference 


Para¬ 

graph 

Number 


3.3.7. 3.1 
33.7.3.2 
33.7.4 


3.3.7  6 


3.3.7  8 
3.3.7  9 
3.3.7.10 


3.3.7.11 


Table  1-1 

Content  Requirements  of  M1L-M-25095A  Related  to  Formats 
( Continued ) 


Procedural _ 

u  .  Trouble-  8 

Maintenance  *00,^  E  c 

Tracks  Tracks  |  l 

nrrs  1 12 13  &  s. 


Section _ Maintenance  Instructions  (Each  LRU) 

Limited  Maintenance  Instruction  Table 
Inspection  Instructions 
Malfunction  Isolation  Procedures 
Prefunctional  Checks 
Functional  Checks 
Disassembly  Procedures 
Detail  Parts  &  Assembly  Checkout 
Cleaning  Instructions 
Lubrication  Instructions 
Reassembly  &  Final  Inspection  Instructions 
Alignment  Checkout  Instructions 
Circuit  Analysis  (Detailed) 

Signal  Flow  &  Schematic  Oiagrams 
Final  Test  Instructions 


3.3.8  Alphabetical  Index 


General  Requirements  Related  to  Formats 


3.2.63 

3.2.6.3.1 

3.2.6.33 

3.2.6. 3.3.1 
3.2.6.3.32 

3.2.6.34 

3.2.6.35 

3.2.6.36 
3.2.6. 3.6. A 
32.6.3.7 

3  2.6  3.8 
3.2.6.39 
3.2.6.3.10 
3.2.65 


Diagrams 

Explanatory  Text  (for  diagrams) 

Schematic  Diagrams 

lnte;cc.r..-,i.ction  diagrams 
Power/oontrol  circuit  &  signal  flow 
Equipment  schematics 
Overall  schematic  diagrams 
Power  &  control  schematics 
Logic  diagrams 
Waveform  diagrams 
Interconnection  cable  diagrams 
Combination  (waveform/interconnect)  diagrams 
Module  schematic  diagrams 
Test  Point  Identification 
^able  Fabrication  Instructions 


NOTE:  Question  mark  (7)  indicates  applicability  or  category  assignment  is  not  firm. 
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In  order  to  satisfy  these  criteria,  a  core  system  of  formats 
was  selected  that  comes  closest  to  meeting  the  collective  goals 
and  that  can  be  adapted  and  modified  to  meet  the  needs  of  each 
category  of  data  in  the  automated  delivery  system.  The  core 
system  selected  was  the  Job  Guide  Technical  Order  System 
( JGTOS ) ,  basic  requirements  for  which  are  contained  in  specifi¬ 
cation  MIL-M-38800A (USAF) .  The  specific  formats  which  are,  or 
may  be,  included  in  the  JGTOS  are  identified  in  Table  1-2. 

1.3.4  JGTOS  Selection  Rationale 

The  justification  for  selection  of  JGTOS  as  the  core  JPA  system 
is  as  follows: 

a.  JGTOS  encompasses,  or  provides  for,  most  of  the  specific 
format  candidates  believed  to  be  appropriate  for  automated 
technical  data. 

b.  JGTOS  is  compatible  with  the  conduct  of  detailed  task 
analysis  as  a  prerequisite  for  preparation  of  technical  data 

c.  JGTOS  is  compatible  with  other  primary  specifications 
containing  guidance  for  selected  format  candidates. 

d.  Although  JGTOS  is  a  JPA  system  for  organizational  level 
maintenance,  it  is  compatible  with  the  applicable  specifi¬ 
cations  for  intermediate  level  maintenance  for  the  types  of 
equipment  anticipated  in  this  program  (i.e.,  MIL-M-25095A; 
MIL-C-38720A) . 

e.  JGTOS  is  already  widely  used  in  the  Air  Force,  so  its 
characteri  st.ics--even  when  applied  to  intermediate  level 
and  converted  to  automated  delivery  form--will  be  familiar 
to  many  USAF  technicians. 


Table  1-2 

Formats  Included  in  Job  (iuidc  Technical  Order  System  (JGTOS) 


JGTOS 

Job  Guide  Technical  Order  System 

♦  CL<a> 

Check  Lists 

a  JG1M 

Job  Guide  Index  Manual 

•  jc;  m 

Job  Guide  Manuals 

a  JOBGUDE 

♦  1CP 

Input  Conditions  Page 

♦  MJG 

Maintenance  Job  Guide 

a  Ti)db) 

Troubleshooting  Data  Charts 

A  TLT(b) 

Troubleshooting  Logic  Trees 

A  SBD<b)<l> 

Schematic  Block  Diagrams 

A  MDdb)<c> 

Maintenance  Dependency  Charts 

•  MSIM 

Maintenance  Support  Information  Manual 

•  GAEM 

General  Aircraft  Equipment  Manual 

•  WDM 

Wiring  Diagrams  Manual 

♦  DCH 

Designation  Cross  Reference 

♦  PLDG 

Physical  Location  Drawings 

♦  WD 

W  iring  Diagrams 

Checklists  arc  optional:  when  provided.  MII.-C-9927  and  Mil.  C-3B778  appl 
Troubleshooting  data  may  be  either  TIKI  Tl.T.  or  Sill*  and  MUG. 

Slllts  and  MltGs  per  Mil  M  38799. 

AFHK1.  TK-80-50  (Kef.  1) 
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1.3.5  Spec ific  Format  Candidates 

The  core  system  encompassed  by  JGTOS  will  be  supplemented  and 
modified  by  the  addition  and/or  substitution  of  other  specific 
torn.at  candidates  in  order  to  provide  the  following: 

a.  The  optimum  data  format  considering  the  needs  of  the  users. 

b.  Satisfaction  of  the  content/format  requirements  of 
MIL-M-25095A. 

c.  Compatibility  with  automated  delivery  system  capabilities. 

The  specific  formats  recommended  for  use  in  the  automated 
delivery  system  are  identified  in  Table  1-3,  together  with  the 
specifications  that  provide  procedures  preparation  guidance  and 
the  location  (as  categories  of  data)  in  the  automated  data  base. 
As  shown,  many  formats  are  based  directly  on  the  requirements  in 
‘1  i  I.-';- 38800A  for  JGTOS.  Others  will  use  JGTOS  formats,  but  will 
be  prepared  to  the  basic  requirements  of  other  specifications. 

In  a  few  cases,  formats  not  encompassed  by  JGTOS  will  be  used, 
cither  as  substitutes  for,  or  supplements  to,  JGTOS  formats. 

Fur  example,  while  JGTOS  (per  MIL-M-38800A)  provides  for  the 
.  v  :>  ‘  logic  trees  as  troubleshooting  procedures,  very  little 
;  regulation  guidance  is  provided  and  there  are  no  provisions 
:  i  :  i  ;  (nonces  in  level  of  detail.  Consequently,  logic 
' i  ‘ os  to  be  used  will  conform  to  the  concepts  defined  in  AFHRL 
■;  1  -  Similarly,  some  specific  formats  in  JGTOS  will  be 

• . -expropriate  for  the  automated  delivery  system  if  they  are 

prepared  to  the  requirements  of  MIL-M-83495 (USAF) ,  which  is 
mirnar  m  many  respects  to  MIL-M-38 800A . 


Table  1-3 

Candidate  Formats,  Requirements  Speeifirations,  and  Categories  of  Data 
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SECTION  2.0 

BASELINE  REQUIREMENTS  FOR  SELECTED  FORMATS 

2.1  FORMAT  DESCRIPTIONS 

This  section  contains  brief  descriptions  of  the  formats  recom- 
n ended  for  use  in  the  automated  delivery  system.  These 
eercr iptions  deal  with  the  formats  as  they  are  used  in  a  paper- 
based,  or  hard-copy,  technical  manual  program.  Formats  for 
non-troubleshooting  maintenance  procedures  are  discussed  in 
Subsection  2.2.  Formats  for  troubleshooting  and  fault  isolation 
procedures  are  discussed  in  Subsection  2.3.  Procedural  support 
and  reference-type  pool  data  formats  are  described  in  Sub¬ 
section  2.4. 

Specific  changes  that  will/nay  be  required  to  convert  these 
formats  for  videoscreen  presentation  are  addressed  in  more 
detail  beginning  in  Section  3.0. 

2.2  NON -TROUBLESHOOTING  MAINTENANCE 
PROCEDURE  FORMATS 

2.2.1  Intermediate  Level  Maintenance 
Functions 

Although  the  specific  non-troubleshooting  (NTS)  maintenance 
functions  to  be  performed  will  vary  with  the  particular  system/ 
equipment  to  be  maintained  and  the  applicable  maintenance 
concept,  the  following  functions  should  be  anticipated: 

•  Inspection 

•  Cleaning 

•  Disassembly  or  removal 

•  Assembly  or  installation 

•  Lubrication 


A 


Input  Conditions  Format 


The  input  conditions  format  is  common  to  all  Job  Guide-type 
procedural  data.  It  contains  all  of  the  information  required  by 
the  technician  in  order  to  prepare  for  the  conduct  of  a  specific 
maintenance  task.  Input  Conditions  Pages  (ICPs)  (see  Figure  2-1) 
are  required  in  the  JGTOS,  per  MIL-M-38800A,  and  in  the  OMMS* 
system,  per  MIL-M-83495.  A  nearly  identical  format,  termed 
Preliminary  Information  Page  (PIP) ,  is  required  in  the  AF/FPJPA** 
system,  per  AFHRL  TR-73-43.  A  slightly  different  approach  is 
the  Summary  Maintenance  Procedure  (SUMP) ,  used  by  the  Army  in 
the  SPA***  system.  While  format  and  content  are  somewhat 
different,  the  SUMP  serves  the  same  purpose  as  the  ICP  and  PIP. 
Requirements  for  SUMP  are  contained  in  MIL-M-63038A .  For  the 
automated  delivery  system,  the  ICP  format  and  the  task  list  as 
used  in  the  SUMP  format  will  be  combined.  A  typical  Summary 
Maintenance  Procedure  is  illustrated  in  Figure  2-2. 

The  input  conditions  frames  will  contain  the  following  types  of 
information,  as  applicable: 

•  Task  title 

•  Applicability 

•  Supplies 

•  Personnel  required 


*OMMS :  Organizational  Maintenance  Manual  Set. 

**AF/FPJPA :  Air  Force  Fully  Procedural  Job  Performance  Aid, 

*  *  *£PA :  Skill  Performance  Aid. 
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Figure  2-1.  Example  of  Input  Conditions  Pages  (ICPs)  in 
Air  Force  Job  Guide  Manual  (reduced  size). 


List  Of  Tasks 

Troubleshooting 

Ref  No  ‘ 

(Para) 

Task 

No 

Task 

Task 

Ref 

1. 

Maintain  Battery 
a.  Check  electrolyte  level 

3-9 

3-10 

b  Check  specific  gravity 

3-9 

3-10 

2 

Service  tracks  and  rollers 

5-7 

5-6 

3. 

Service  radiator: 
a.  If  temperature  can  go 
below  ♦  32  deg  F„  check 
antifreeze 

Add  antifreeze 
if  necessary 

b  Check  coolant  level 

Add  coolant,  if 

necessary 

4. 

Install  and  adjust  fan  belt 

4-6 

4-7 

5 

Clean  winch  and  oil  screen 

5-7 

5-9 

Figure  2-2.  Example  of  Summary  Maintenance  Procedure 
(SUMP)  (from  MIL-HDBK-63038-1 ) . 

•  Replacement  parts 

•  Equipment  conditions 

•  Support  equipment 

•  Special  tools  and  test  equipment 

•  Safety  and  warning  statements 

•  Task  summary. 

Input  conditions  may  be  complete  in  one  frame,  or  may  use 
multiple  frames.  Baseline  requirements  are  those  contained 
in  MIL-M-38800A,  supplemented  by  MIL-M-83495  and  MIL-M-63038A. 
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The-  input  conditions  format  will  be  used  for  all  three  tracks  of 
lb  n t rr.blr shoot ing  maintenance  procedures.  For  Track  2  and 
"’rack  3  maintenance,  the  input  conditions  frame (s)  is  preliminary 
to  Lite  actual  procedural  data.  For  Track  1  maintenance,  the 
input  conditions  frame  (s)  including  the  summary  of  tasks — may  be 
used  by  experienced  technicians  to  perform  maintenance. 

Tmo  TCh  format  has  not  been  specifically  tested,  since  it 
cent  iinj  no  procedural  data.  Tests  of  Job  Guide  procedural 
formats  have  included  the  ICP,  however.  Relevant  descriptions, 
illustrations,  and  requirements  information  for  the  input 
conditions  format  for  the  electronic  delivery  system  are 
contained  in  Section  7.0. 

-  *- •  ’  Duax-Level  Maintenance  Instruction 

Format 

The  dual -level  maintenance  instruction  frame  format  is  a  hybrid 
of  rully  proceduralized  and  partially  proceduralized  maintenance 
instructions,  accompanied  by  specific  illustrations  of  the 
equipment  being  maintained.  In  this  approach,  primary  steps  are 
in  bold  face  type  (or  underlined),  with  detailed  steps  in  normal 
type.  Callouts  in  the  text  steps  reference  specific  components 
in  the  accompanying  illustration  (see  Figure  2-3). 

This  combination  provides  (in  the  detailed  steps)  specific 
instructions  on  what  to  do  and  how  to  do  it.  The  primary  steps 
serve  to  alert  the  technician  to  the  scope  of  the  underlying 
detailed  steps,  and  can  be  used  as  a  checklist  by  technicians 
with  enough  experience  to  not  need  the  detailed,  fully  proce¬ 
dure  lized  steps.  The  dual-level  presentation  mode,  containing 
both  primary  and  detailed  steps,  is  required  by  MIL-M-38800A ? 
additional  guidance  is  contained  in  AFHRL  TR-74-12  and 
DOb-f  Til-]  685. 
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The  dual-level  format,  with  fully  keyed  illustrations,  will  be 
used  for  Track  3  non-troubleshooting  maintenance.  In  addition, 
it  is  the  basis  for  preparing  the  instructions  to  support 
Track  2  maintenance.  The  latter  will  use  only  the  primary 
(boldface)  steps  of  the  dual-level  presentation,  without  the 
detailed  steps.  To  these  primary  steps  will  be  added  such 

•  >ther ,  more  specific  information  as  is  needed  to  make  the  step 
complete  or  to  provide  critical  data.  Keyed  illustrations  may 
be  used,  but  will  contain  less  detail  than  in  the  Track  3 
level.  Figure  2-4  illustrates  the  change  to  the  dual-level 
format  when  the  detailed  steps  are  deleted.  The  Track  2  format 
will  be  somewhat  similar  to  that  required  by  MIL-C-38720A,  for 
Intermediate  Maintenance  Checklists.  As  mentioned  earlier. 

Track  1  non-troubleshooting  maintenance  will  rely  on  the  Summary 
Maintenance  Procedure  format  that  is  part  of  the  input  conditions 
for  all  tracks. 

Sample  formats  and  preparation  guidelines  for  automated  mainte¬ 
nance  procedures  are  contained  in  Section  7.0. 

2.3  TROUBLESHOOTING  AND  FAULT  ISOLATION 
PROCEDURE  FORMATS 

2.3.1  In termediate  Level  Troubleshooting 
Functions 

Specific  troubleshooting  functions  to  be  performed  will  vary 
with  the  particular  system/equipment  and  the  maintenance  concept. 
The  following  functions  should  be  anticipated  at  both  the  system 
level  and  the  equipment/component  level: 

•  Checkout 

•  Test 

•  Fault  isolation. 
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2.3.2  Loqic  Tree  Troubleshooting  Aid 
TLTTAT~  rormats 

logic  Tree  Troubleshooting  Aids  (LTTAs)  have  two  essential 
components:  checkout  procedures  and  logic  trees.  Checkout 

procedures  are  a  series  of  sequential  steps,  or  checks,  to 
identify  the  existence  of  a  malfunction  in  a  particular  portion 
of  a  system  or  equipment.  Logic  trees  are  "branching"  steps 
arranged  in  a  sequence  that  will  quickly  isolate  the  cause  of 
the  fault  to  a  particular  component  or  assembly;  the  quantitative 
or  qualitative  results/observations  of  each  step  determine  which 
of  the  branches  to  follow  in  the  next  step.  Logic  trees  are 
almost  always  binary/  i.e.,  there  are  always  two,  but  not  more 
than  two,  possible  next  steps. 

LTTAs  can  be  presented  in  many  forms:  all  narrative,  charts, 
tabular,  flowcharts,  or  combinations  of  each.  For  this  program, 
troubleshooting  will  be  accomplished  using  versions  of  the  LTTA 
format  prepared  according  to  AFHRL  TR-79-49.  These  LTTAs 
combine  the  use  of  checkout  procedures  (in  narrative  form)  to 
identify  a  malfunction,  symptom  tables  to  provide  a  cross- 
reference,  and  logic  tree  flowcharts  to  isolate  the  cause  of 
the  malfunction  and  direct  corrective  action.  Further,  this 
approach  provides  for  varying  the  level  of  detail  in  the  check¬ 
out  procedures  and  logic  trees  according  the  the  skill  level 
and  experience  of  the  intended  users.  (Although  MIL-M-38800A 
authorizes  the  use  of  LTTAs,  the  guidance  therein  is  not 
sufficient  for  preparation.) 

Track  3  troubleshooting  will  use  the  fully  enriched  version  of 
the  checkout  procedures,  in  dual-level  presentation,  as  shown 
in  Figure  2-5.  Fault  isolation  in  Track  3  will  use  the  fully 
enriched  logic  trees,  illustrated  in  Figure  2-6.  Full  enrichment 
as  used  in  this  specification,  means  that  the  detailed  steps 


Figure  2-6.  Example  of  LTTA  fully  enriched  logic  tree 
(from  AFHRL  TR-79-49) . 


involved  in  accomplishing  the  task  are  clearly  described  in 
their  proper  sequence,  and  accompanied  by  detailed  and  appro¬ 
priately  keyed  illustrations. 

Track  2  troubleshooting  will  be  accomplished  with  minimally 
enriched  checkout  procedures  and  logic  trees.  The  level  of 
detail  in  the  checkout  procedure  will  approximate  that  specified 
for  the  Track  2  maintenance  procedure  (see  paragraph  2.2.3  and 
Figure  2-4) .  An  example  of  a  minimally  enriched  logic  tree  is 
shown  in  Figure  2-7.  Illustrations  will  also  be  provided  in 
Track  2,  but  with  less  detail  and  minimum  use  of  callouts. 

Track  1  troubleshooting  will  use  completely  unenriched  versions 
of  the  LTTAs  in  narrative  checklist  form.  Checkout  procedures 
will  not  be  significantly  different  from  those  shown  in  Figure  2-5 
except  that  the  level  of  detail  will  be  much  reduced.  Fault 
isolation  procedures  will  use  a  "logic  checklist"  for  each  fault 
found  in  the  checkout.  The  sequence  of  fault  isolation  steps 
will  be  the  same  as  in  the  more  detailed  tracks  but  the  logic 
will  be  transparent  to  the  technician.  As  in  the  checkout 
procedures,  guidance  for  performing  each  check  will  be  limited 
to  essential  information  which  even  these  more  skilled  technicians 
may  require.  In  addition.  Track  1  technicians  may  obtain  pool 
data  such  as  schematics  and  test  specification  charts,  and  use 
them  either  as  supporting  data  or  as  substitutes  for  the  logic 
checklists . 

Sample  formats  and  preparation  guidelines  for  automated  trouble¬ 
shooting  procedures  are  contained  in  Section  8.0. 
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2.3.3  Fault  Code/Cross-Reference  Index 


This  format,  illustrated  in  Figure  2-8,  may  be  used  in  all  three 
troubleshooting  tracks  if  the  fault  code  reporting  system 
specified  in  MIL-M-83495  is  in  use  with  the  system/equipment. 
Level  of  detail  will  be  the  same  for  all  three  tracks.  Guidance 
regarding  the  Fault  Code/Cross-Reference  Index  is  contained  in 
AFHRL  TR-79-49 . 


Figure  2-8.  Example  of  Fault  Code/Cross-Reference  Index 
(from  AFHRL  TR-79-49) . 
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2.3.4  Other  Troubleshooting  Formats 

Al  !  other  infr,j  ;-..j  t  ion  which  r  ay  be  used  to  support  trouble¬ 
shoot  :  n->  is  p  ir  t  of  :  hr  pool  data,  discussed  in  Section  5.0. 

2.4  ,  OOL  LV  TA  FOiO'A'1  :: 

2.4  i  .  a  (’■  -u  a  ue  •.  ions 

It  r.  *  a:.-;e  of  ;  or mats  cc-.pr  isir.g  "pool  data"  is  extremely  broad, 
vary.in  ■  f  rot;,  that  for  a  technical  manual  title  page  to  a  schematic 
Jiao ran.  For  convenience,  pool  data  has  been  arbitrarily  divided 

i  n to  two  c a t e . . o : i e s  : 

*? .  Pr  >c<"*r»ura  i  support  data,  which  are  used  primarily  to  amplify 

or  riaiify  a  specific  maintenance  or  troubleshooting  procedure, 
cr  otherwise  assist  in  rccoirpl  ishing  a  task. 

h.  h(.  erencc  PLii,  which  provide  general  information  about  the 
system  or  equipment,  or  about  the  TO  itself. 

The  discussion  in  this  section  will  deal  primarily  with  the 
l  rocedu: al  support  pool  data  formats,  with  brief  mention  of 

the  reference  pool  data  formats. 

2 . 4 . 2  T 1 i nstr n ted  Pa r ts  3re a kd own  (IPB) 

A ;  tiheu  il  ,V7L~.“!-2  50  9  5A  contains  no  requirement  for  preparation 
-•  f  an  IPB,  .it  is  frequently  a  part  of  intermediate  maintenance 
...munis,  and  it  rust  be  assumed  that  an  IPB  will  be  required, 
o  nt.ont  specif  i  cat  ions  frequently  do  not  mention  the  IPB 
lequircment  since  it  in  often  in  a  separate  manual  (from  the 
,  a  ini  er.-u.ce-'ti  v  h.  eshoot  in::  procedures)  and  is  prepared  to  the 
:  >■  :u  ,  n-ueiit.  r .  ‘  a  different  specification.  The  TO  manager  of 
•  he  au  pj  j  sj  t  *  n  .money  may  make  a  determination  that  the  IPB 
manual  cun  be  combi  nod  with  the  maintenance  manual — the  likely 


2-1  5 


(and  preferred)  approach  in  the  automated  delivery  system. 
Nevertheless,  it  is  suggested  that  the  IPB  be  considered  as  a 
discrete  "section"  of  the  automated  data  base  since,  in 
practice,  it  will  often  be  used  as  an  entirely  separate  manual. 

For  many  years  all  three  military  services  used  the  same 
specification  (MIL-M-8910)  as  the  basis  for  IPB  preparation. 
Currently,  however,  IPBs  procured  by  the  Air  Force  must 
conform  with  MIL-M-38807 (USAF) .  Although  basic  requirements 
are  similar,  there  are  significant  differences  in  terminology 
and  format.  It  is  possible  that  the  existing  IPB  for  a  system 
was  originally  prepared  to  MIL-M-8910,  but  it  should  be  assumed 
that  the  requirements  of  MIL-M-38807  will  apply  to  this  program. 

The  principal  parts  of  the  IPB  are: 

a.  Introductory  materials  (Figures  2-9,  2-10,  and  2-11). 

b.  Maintenance  Parts  List  (including  breakdown  illustrations) 
(Figure  2-12) . 

c.  Numerical  index  of  part  numbers  (Figure  2-13) . 

d.  Reference  designation  index  (Figure  2-14) . 

Although  formats  and  arrangements  may  vary  from  MIL-M-38807 
requirements  to  some  degree,  the  automated  IPB  must  satisfy  the 
intent  of  those  reauirements.  Section  6.0  contains  sample 
formats  and  preparation  guidelines  for  IPB  pool  data  in  the 
automated  delivery  system,  including  some  additional  formats 
and  types  of  data  not  needed  in  a  paper-based  IPB. 

2.4.3  Function  Diagrams 

As  defined  in  DOD-STD-1685 (SH) ,  a  function  diagram  is: 
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Figure  2-12.  Example  of  IPB  Maintenance  Parts  List  (MPL) 
with  breakdown  illustration. 
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A  1 ype  of  illustration  ...  in  which  symbols  are 
connected  by  linos  to  show  relationships  among  the 
symbuLs.  The  symbols  may  be  rectangles  or  other 
shapes,  star  bird  symbols  representing  components 
or  fun  c  i or  s. ,  or  pictorials  representing  equipment 
fi  components .  The  lines  may  represent  physical 
thinus,  5,.d  >s  wires,  or  ideas,  such  as  logic 
low.  This  categc-'v  includes  schematics,  wiring 
...nu  p  ipi  r  .  d i  a  rams ,  logic  diagrams,  flow  charts, 
ml  block  d;o  ,  r  r. 

This  let*  ini  tier,  a.xtm.r  as  :  t  applies  to  logic  trees)  is  being 
used  herein,  and  "f  r.rti  n  diagrams"  are  discussed  as  a  group, 

.sinc  e  tern  i  oology  v.  r  -r  considerably  from  one  source  to  the 
next  and  the  distinct  re  tween  the  types  is  net  always  clear, 
for  example ,  wiriivi  d  i ;  r  .c's  ■••’’cure  2-15)  may  be  called  inter¬ 
connect  ion  d  can  rams  ( F  ■  ,r.rc  1-16)  ,  and  schematic  diagrams 
(Figure  k-i  7)  oy  b*.  rail;.:  schematic  block  diagrams  (Figure  2-18) 
or  just  block  cl  u :  ;n;  ,  ••den.  .  c  2-19). 

Ti\e  pr  inn «  y  r.  s-  :>:  lurrovr.  diagrams  is  as  procedural  support 
inforriai.ion  although  rney  t-  ay  also  be  used  as  reference  data 
(as  in  the  Theory  of  Operation  section  of  the  manual).  In 
order  to  achieve  a  common  rose line  for  all  function  diagrams, 

M I L-FTP-8  6  3 A  { [  .•  ,.  ■  /  v  ■'  '  W  I  l  i  DQ  the  uaseline  requirements  document 
t  the  extent  that  j  t  contains  applicable  requirements.  Types 
v. >.  nd.-quati  !  y  »  -;j  by  • .  L-STD-863A  will  be  treated  as 

oxer.  .  n  j ,  will-  s  ..jn-o-.  or  hay  guidance  provided ,  For  example, 
lit"  ■■  pTchcroah-bcf  on  ..tutus  of  DOD-STD-1685  apply  to  all 
f  unc  t  on  do.!  '  ^ ad it  legal  requirements. 

-top  .'.CS  ui  laments  for  certain  text,  lists, 

<.nd  tables  wa  icb  surpl''-  os'  t  tv.  •: 1  a  trams.  Whether  these  spec i a  1  - 
»  /.eh  sub-fur  .-v.  •  b.  ..  v  .  •  g  wi 1  1  depend  to  a  great  extent 

t.h  <■  tv.  i  i  . :.  t  ;.  .  .  vc  t  v  oit  of  the  diagrams  in  relation 

i  •  i  he  .'ep-tt  .  i  i  •;  !  <  v  1 1;  •  •  o'ed  delivery  system  hardware . 


MI1.-M-3B?98(USAP) 


Figure  2-18.  Example  of  function  diagram  (schematic  block  diagram) 


Figure  2-19.  Example  of  function  diagram  (block  diagram 


Sample  formats  and  preparation  guidelines  for  some  anticipated 
types  of  automated  function  diagrams  are  contained  in  Section  6.0. 

2.4.4  Other  Procedural  Support  Pool  Data 

In  addition  to  the  IPBs  and  function  diagrams,  a  variety  of 
other  formatted  data  may  be  required  to  support  maintenance 
and  troubleshooting  procedures.  Specific  features  will  depend 
on  the  particular  system/equipment  data  to  be  presented,  and  the 
manner  in  which  the  data  support  the  procedure.  Some,  such  as 
waveform  guides  which  are  related  to  and  needed  for  a  specific 
procedural  step,  should  be  presented  in  the  same  frame  presen¬ 
tation  as  the  step  to  which  they  apply  (Figure  2-20) ,  as  well  as 
in  pooi.  If  the  support  data  are  applicable  to  a  number  of 
different  steps,  to  a  series  of  tasks,  or  to  a  group  of  equipment, 
the  data  should  be  included  in  pool.  Some  examples  are  access 
and  locator  diagrams,  test  specification  tables,  and  test  setup 
diagrams.  Examples  of  some  of  these  other  supporting  formats 
are  illustrated  in  Figures  2-21  through  2-23.  In  general,  the 
specif ication  requirements  which  apply  will  be,  in  order  of 
preference,  MIL-M-38800A,  MIL-STD-863A,  and  MIL-M-38784A. 

Sample  formats  and  preparation  guidelines  for  various  types 
of  automated  data  in  this  category  are  contained  in  Section  6.0. 

2.4.5  Reference  Pool  Data 

This  category  of  pool  data  includes  a  broad  spectrum  of  data 
and  information,  varying  widely  in  purpose,  content,  and  format. 
Some  information  may  deal  with  non-procedural  technical  data 
about  the  equipment  or  system  (e.g..  Theory  of  Operation),  while 
other  data  deal  with  the  status  of  the  technical  manual  itself 
le.g..  List  of  Effective  Pages).  Guidelines  for  preparation  of 
this  type  of  information  are  generally  straightforward  and  will 


Figure  4-17.  Schmitt  Trigger  and  Gates  Troubleshooting  for 
Failed  Bench  Checkout  Procedure  4-64/5  (Sheet  1) 


Figure  2-20.  F.xaraple  of  procedural  support  data  (waveform  guide) 
included  in  procedural  text  instead  of  in  pool  data 


not  be  detailed  further  here.  Order  of  precedence  for  this 
program  will  be  MIL-M-38784A,  MIL-M-38800A,  and  the  content 
specification  for  the  particular  system.  Note  that  this  type  of 
information  must  be  provided,  as  part  of  an  Air  Force  Technical 
Order,  and  is  no  less  subject  to  specification  requirements  than 
are  the  procedures  themselves. 

Some  of  the  types  of  data  and  formats  that  are,  for  purposes 
of  the  automated  delivery  system,  part  of  the  reference  pool 
data,  but  not  described  here,  include,  but  are  not  limited  to: 

•  List  of  Effective  Pages 

•  Promulgation  Page 

•  Change  Record 

•  Table  of  Contents 

•  List  of  Illustrations 

•  List  of  Tables 

•  Alphabetical  Index 

•  List  of  Time  Compliance  Technical  Orders  (TCTO) 

•  Principles/Theory  of  Operation 

•  List  of  Test  Equipment 

•  List  of  Special  Tools 

•  Special  manufacturing/repair  instructions 

•  System  description  data 

•  Description  of  system  tie-in  of  equipment  and  accessories. 

Samples  of  formats  and  operation  guidelines  for  automated 
reference  data  that  are  comparable  to  paper-based  TO  front 
matter  and  other  reference  data  are  contained  in  Sections  4.0 


2.4.6  User  Instructions 

There  is  one  kind  of  information  that  will  be  needed  in  the 
automated  delivery  system  that  often  is  not  found  in  hard-copy 
TOs :  instructions  for  use.  Conventional  technical  manuals 

rarely  include  any  guidance  to  the  technician  on  how  to  use  the 
manual ,  although  an  access  flow  diagram  may  be  included  for 
using  the  IPB  if  it  is  provided  (see  Figure  2-11).  Some  newer 
job  aids,  e.g.,  Job  Guides,  LTTAs ,  and  Functionally  Oriented 
Maintenance  Manuals  (FOMMs) ,  do  provide  brief  explanations  of 
the  most  effective  ways  to  use  the  manuals,  generally  as  part  of 
the  front  matter.  Examples  of  these  instructions  are  included 
in  Figures  2-24,  2-25,  and  2-26. 

Instructions  to  the  ATO  system  user  will,  of  necessity,  need 
to  be  more  complete  3;nce  the  technician  will  need  to  know  how 
to  operate  a  hardware  system  as  well  as  the  conventions  and 
approaches  used  in  presenting  the  technical  data.  Automated 
delivery  system  instructions  will  be  provided  in  three  ways: 

a.  Through  the  use  of  prompts,  advisories,  and  feedback 
messages  associated  with  each  frame. 

b.  Through  the  use  of  options  lists  associated  with  each 
identifiable  portion  of  the  data  base. 

c.  Through  a  complete  explanation  of  the  system  and  its  use, 
contained  in  the  system  users'  guide. 

Sample  formats  and  preparation  guidelines  for  the  third  approach 
are  contained  in  Section  9.0. 


'ECTION  3.0 


GENERAL  CL  I  RELINKS  AFFECTING  FORMAT  SELECTION 
AND  DEVELOPMENT 


3.1  NTRODLCT1  Of 

The  n.rttorials  in  this  suction  apply  to  the  automated  system  data 
base  ns  a  who  i  e .  '  :.ct  s  ;;<•»: sseU  are  the  defined  baseline 

do  1.  ivory  system,  t'c  rp.v  . .  cr.ei  i  sties  based  on  that  system, 
ihit a  cr  j.inizatioi:  ,.nd  a cc ,  -.quxrements ,  and  standardized 
coding  and  conventions  use.:. 

3.2  THE  VAM1S  SYSTEM  CONCEPT 

The  concept  of  the  system  in  . tc  simplest  form  is  to  replace  the 
shelves  and/or  file  cabinets  filled  with  paper  copies  of  Technical 
(  tiers  with  a  computer-bad  system  that  will  have  all  of  the 
advantages  of  a  paper-based  "O  system  and  few,  if  any,  of  the 
disadvantages.  Further,  the  system  should  eliminate,  to  the 
extent  feasible,  the  deficiencies  that  are  commonly  associated 
v.  i  th  computer-based  systems  with  which  people  interact.  These 
general,  and  optimistic,  no..s  ]  s  have  led  to  the  definition  of  a 
prototype  automated  delivery  system  as  a  baseline.  This 
conceptual  system  tins  been  -  a  an  the  descriptive  name  of  VAMIS , 
for  ’.’or  sat  ilc  Automated  Maintenance  Information  System. 

A  principal  object  ive  of  tnr.  s\  stem  prototype  definition  program 
was  to  provide  for  off  1  j  yc  anal  efficient  interaction  between 
the  if.1!  (technician)  and  'be  system.  This  has  resulted  in 
defining  three  d.i  f  l  erent  "  ->s  of  interaction,  each  with  certain 

constraints  and  c:  t  tin  utv!  ...  L  characteristics:  the  standard 
mode,  the  user  re,  ;uest  ,  ..no  the  review  mode.  These  modes 

c  f  interaction  are  be fori  In  in  Eubsection  3.6. 


As  noted  in  subparagraph  1.3.1.f,  early  program  development 
activities  resulted  in  definition  of  a  baseline  hardware  system 
for  preparation,  management,  and  presentation  of  data.  The 
three  principal  elements  of  the  hardware  system  are  the  compute 
subsystem,  display  subsystem,  and  control  subsystem.  Charac¬ 
teristics  of  these  three  subsystems  that  relate  to  format 
selection  and  development  are  discussed  in  Subsections  3.3, 

3.4,  and  3.5,  respectively. 

3 . 3  COMPUTER  SUBSYSTEM 

The  computer  selected  as  the  baseline  for  this  program  was  the 
Digital  Equipment  Co.  VAX  computer.  This  selection  was  based 
on  the  computing  power  available  for  data  preparation  and 
management,  software  availability,  and  compatibility  with 
peripherals.  A  detailed  description  of  the  computer  system  is 
beyond  the  scope  of  this  document.  The  formats  that  have  been 
designed  and  the  modes  of  use  that  have  been  established  are 
completely  compatible  with  the  VAX  computer  programming  and 
memory  requirements. 

3.4  DISPLAY  SUBSYSTEM 

3.4.1  Presentation  Device 

The  baseline  video  display  for  this  program  is  the  Megatek  7000 
Although  it  is  not  required  that  only  this  unit  be  used  for 
system  data  presentation,  the  characteristics  and  capabilities 
of  the  display  device  do  impose  certain  constraints  on  the 
characteristics  of  the  formats  used  and  the  manner  of  their 
presentation.  If  other  display  devices  are  used,  appropriate 
adjustments  to  the  formats  and  guidelines  described  in  this 
document  will  be  required.  In  addition,  this  program  was 
constrained  by  the  requirement  to  use  a  single  display  device. 


Use  of  a  dual  display  can  have  some  significant  advantages  and 
may  permit  (or  require)  some  different  format  and  content 
character. ist Lcs ,  and  wild  probably  require  modification  of  the 

control  unit  design  'not  Subsection  3.5). 

3 . 4  .  Z  3c i  ci  :  "  amur  U 

l* i  gure  3-1  i  I  .  as >  i  .i .  i-s  tut.  p !  j  ncipai  factors  related  to  the 
baseline  dis;:i  a-,  that  irileenoe  format  development  and  data 
preparation.  Fm'wst*  ar*»  l he  screen  size,  the  portion  of  the 
screen  that  cm  be  e  iect  veiy  utilized,  and  the  amount  of 
information  that  can  be  displayed  under  the  conditions  specified 
for  tne  program.  Also  or  concern,  but  not  discussed  in  detail 
here,  arc  the  rrebj  tr.  of  the  display  for  presentation  of 
complex  graphics  and  for  Che  use  of  color. 

The  Mcgatek  7000  is  a  high-resolution  (4096  x  4096  addressable 
and  viewable)  display  usi ng  stroke  display  technology  and  vector 
storage  format.  The  screen  size  is  21  inches  diagonal  measure. 
Other  characteristics  are  4:1  contrast  ratio,  unlimited  windowing 
zoom  (1-16),  anu  capabilities  for  scrolling,  panning,  blinking, 
and  rotation.  Guide  1 ines  l or  use  of  color  in  formats  are 
provided  in  Subsection  3.9,  but  are  independent  of  the  Megatek 
display  capabilities. 

Specifications  for  CRT  devices  will  generally  make  a  distinction 
between  the  viewable  arc.*  ( ; he  total  dimensions  of  the  screen) 
and  the  content  are.?.  vth  utt.jon  of  the  screen  that  can  be 
effectively  used  for  pree  rotation  of  information).  The  differ¬ 
ence  between  the  two  (the  mat  gin)  comprises  screen  space  that 
either  cannot  bo  used  because  characters  cannot  be  displayed 
there,  or  should  not  be  u  uocause  of  factors  such  as  character 
distortion.  live:.  when  ch-or  factors  do  not  exist,  planning  for 
usab’c  content  a:-.n  she;.  provide  for  a  margin  so  that  when  the 
technician  j  c>  viewing  Lh.  or- -on  from  an  angle,  content  is  not 


obscured  by  the  screen  flanges.  For  the  Megatek  display,  the 
margins  are  approximately  1  inch  on  each  side  and  1/2  inch  on 
the  top  and  bottom,  permitting  an  approximately  square  content 
area. 


NOTE:  Screen  size  in  this  example  is  approximately  39%  of 

the  actual  screen  size  of  the  Megatek  7000  display. 


Figure  3-1.  Characteristics  of  Megatek  display  screen 
affecting  format  organization  and  layout. 


Displayable  content,  in  terms  of  numbers  of  characters  and 
lines,  is  a  function  of  the  required  viewing  distance,  the 
character  size  required  for  legibility  at  that  distance,  and  the 
character  sizes  that  can  be  displayed.  Viewing  distance  require 
ments  for  this  program  are  6  feet  for  procedural  data  and  3  feet 
for  pool  data.  These  requirements  should  be  satisfied  when  the 


frame'  first  appears  on  me ■  screen,  without  subsequent  magnifi¬ 
cation  (or  "room" ),  in  ail  cases  except  some  complex  illustrations 
cental nc-t1  in  pool. 


3.4.  j  Character  1 2-1 


Research  on  CRT  crirac tc -  end  symbol  legibility  has  provided  a 
ranee  of  from  5  'dnul.es  os  uor  optimum  viewing  conditions) 

to  more  than  20  minutes  0/  . ; v  lot  the  visual  angle  which  should 

subtend  at  the  eye  a*,  the  inquired  viewing  distance.  Most 
researchers  agree  tune  from  10  to  15  minutes  of  arc  is  adequate 
except  for  complex  symbols  and  graphic  details,  or  for  degraded 
v  u:winq  conditions  (Ref.  3;  Ref.  .10;  Ref.  11;  Ref.  12; 

M i T,- STD-  147  2C)  .  Whil  1  iron,,  repor  ts  treat  this  relationship 
between  character  height  \  1.  f  viewing  distance  as  linear,  some 
evidence  suggests  that  the  visual  angle  required  is  non-linear, 
decreasing  slightly  as  mowing  distance  increases.  For  the 
automated  delivery  system,  the  visual  angle  (and  resultant 
character  sizes)  shown  in  Table  3-1  was  selected. 


Table  3-1 

Character  and  Simple  Symbol  Height  Requirements 


Drii-.i  Type 


T’j'ocedurcs 


M  1  aimed" 
V 1  owing 
hist  a  n.,c 


Visual  Angle 
(min.  of  arc) 


Character  Height 


Inches 


0.209 


0.126 


5.32 


3.20 


The  V.cuutck  tli 
d  1  delayed  at 


a  ;  uu.lard  character  set  that  can  be 
!'•  dm  as  shown  in  Table  3-2. 


Love]  5  aid  Lev 


v-  1  3  .n.i  :-:.>ws  wore  selected  for  presentation 
data  a -mi  get  I  data,  respectively,  providing  the 


of  procedural  data  au-.i  gee  I  data ,  respect 
content  crapab.i  1  ii  1 1.  s  ■  *.  in  Figure  3-1. 


Table  3-2 


Character  Sizes  Available  from  Megatek 
Standard  Character  Set 


_ Character  Width _  Character  Height _ 

Level  (Res.  Elements)  (Inches)  (Res.  Elements)  (Inches) 


0 

8 

.024 

12 

.306 

1 

16 

.048 

24 

.072 

2 

24 

.072 

36 

.108 

3 

32 

.096 

48 

.144 

4 

40 

.120 

60 

.180 

1  5. 

48 

.144 

72 

.216 

6 

56 

.168 

84 

.252 

7 

64 

.192 

96 

.288 

3.5  CONTROL  SUBSYSTEM 


3.5.1  Requirements  Definition 

The  preliminary  definition  of  the  automated  delivery  system 
included  a  determination  of  the  type  of  control  device  to  be 
used  by  the  technician  to  interact  with  the  system  and  the 
interactive  capabilities  that  should  be  present  on  the  control 
device . 


As  is  the  case  with  practically  all  commercial  video  display 
terminal  (VDT)  keyboards,  the  standard  keyboard  which  accompani 
the  Megatek  display,  while  useful  for  programming  and  for 
supervisory  interaction  with  the  system,  was  inappropriate  as 
the  control  interface  for  system  users.  Accordingly,  analyses 
were  performed  to  optimize  the  control  interface  among  the 
technician,  the  system  capabilities,  the  modes  of  use,  the 
contents  of  the  data  base,  and  the  characteristics  of  the  forma 
technical  information.  The  system  characteristics  and  the  mode 


ed 


te 


of  user  interface-  with  the-  system  resulted  in  requirements 
for  an  alphanumeric  keypad  and  a  function  keypad,  integrated 

into  a  single  rcneiol  u  'it. 

The  capability  i v  i  ?.  ••  ;  the  display  from  distances  up  to  six 

f  c v  i  imposed  a  s.  vordnry  uu  ,  ire-nent  that  the  control  unit  be 
capable  of  pcs  t  i  o.  .  g  a  r_.  i  lar  distance  from  the  display,  with 
repos i t inning  as  nc obe-i  , de;  endentlv  of  the  display.  This  will 
pi  rn.it  the  technician  to  '.•-op  r.he  control  unit  at  the  worksite 
wi'.ilo  viewing  the  display.  besign  characteristics  needed  are 
small  sice  and  weight,  case  of  handling,  damage  resistance,  and 
ease  of  interconnection  witn  the  computer/display  subsystems. 

Control  unit  design  was  based  on  interfacing  with  a  single 
display  screen.  Use  of  a  dual  display  would  probably  dictate 
several  additional  f  no non  keys,  and  possibly  a  rearrangement 
of  the  functional  groups. 

3.5.2  Con f i gurat ion 

A  prototype  control  unit  was  defined  and  designed  to  achieve 
compatibility  among  the  computer  subsystem,  the  display  sub¬ 
system,  and  the  user.  The  configuration  of  the  control  unit 
attempts  to  optimize  tin-  user/control  interface,  especially  in 
the  allocation  of  { unction  keys,  which  are  directly  associated 
with  system  instructions  end  standard  frame  content  items.  This 
integration  is  especial  t  /  ..levant  in  the  content  of  prompts  and 
feedback  messages  and  in  t':v  user  request  mode  of  interaction. 

Tine  general  conf  i  gurat  rm  of  the  control  unit  is  depicted  in 
Figure  3-2.  The  o' it  :•  icitag  i  ng  is  based  on  requirements  for 
portability,  ru  .  ycne  ■  ■■■ ,  .....  user  access  in  a  shop/workbench 
type  of  environment.  ini  ..•  connection  with  the  computer/display 
subsystems  is  astumoi  ;  - •  through  workbench  busses  to  avoid 


lengths  cabl  in, .  'I':.*  ■  ,na'  features  a  carrying  handle  which,  when 

locked  in  position,  serve?  us  the  "back  legs"  to  improve  user 
access  and  view,  .in  mu’  :  In  the  upright  position  (carrying  and 

slow  *  the  handle  yi^vi  ies  for  stowage  of  the  interconnection 
cable.  Individual  key;  are  flush-mounted,  under  a  sealed  trans- 
pa  r>:  v*  overlay,  using  a  fiat-  ianel  keyboard.  The  control  unit 
is  thus  s  aled  against  entrv  of  shop  pollution  and/or  atmospheric 
ccndi'ucnr.  Ka  i  sed  koss  vo<;  id  improve  the  tactile  interface  but, 
with  currently  available  tea  : .no logy,  would  sacrifice  the  sealed 
control  unit.  User  feedback  at  the  control  unit  is  limited  to 
the  tactile  feedback  when  a  key  is  depressed;  all  visual 
feedback  is  on  the  display  screen.  Figure  3-3  illustrates  the 
panel  configuration  and  Key  assignment  for  the  control  unit. 


3.5.3  Control  FurictJ  ons 

,'.3  c:n  be  seen  in  rl.g,..te  3-3,  the  keyboard  functions  are 
acran.ed  in  live  control  groups,  as  follows: 

j.  Display:  This  group  is  used  to  activate  and  deactivate  the 
display.  hone  of  the  other  keys  on  the  control  unit  are 
functional  unless  the  display  has  been  activated. 

.  control :  Th :  s  group  contains  the  keys  which  are  used  to 
toll  the  computer  where  the  user  wants  to  go  in  the  data 


S.-re-n ;  This  group  is  used  to  control  the  size  and  position 
on  • hr  screen  of  illustrations  which  are  being  displayed. 

V(j>: l  j;,  i.o :  affected  by  these  controls. 


V|,  .p ,  ,  j  V  *  rJ’li  ;  y 

.  ;i  I  >')n:i:i  1 1  on  zr 


;  ;■  used  to  retain  specific  frames  of 
od  by  the  user  and  show  them  again  later 


when  n-'Te 


In;  u :  : 


f  roil  ; j  ■ 


u  vo  the  ;o-  inti- 


fd.r  o:  ions  of  <  a. 


.030:  ll'Ui 


rs  the  keys  used  for  making  a 
nn  natives  which  may  be  offered  and  to 
.y.ci'ic  instructions  about  what  is  wanted 

:  ■  '  <■<•  keys  comprising  these  groups  are 

.eluding  their  application  to  each  of 
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Table  3-3 

Description  of  Control  Unit  Key 
Functions  and  Applications 


Mode  of  Use 


Function 


User 

Standard  Request  Review 


START  Activates  the  display  and 

control  unit.  Indicates  to 
the  system  that  a  new  user 
wants  to  log  on. 

STOP  Logs  out  the  present  user  and 

deactivates  the  display  and 
the  control  unit. 


FORWARD  Instructs  the  system  to 

provide  the  next  frame  in  an 
ordered  sequence  of  frames. 

REVERSE  Instructs  the  system  to 

provide  the  last  previous 
frame  wit  in  a  pre-established, 
ordered  sequence.  (User  will 
not  necessarily  see,  in 
reverse  order,  what  was 
previously  displayed.) 

System  will  not  reverse  past 
the  first  frame  of  a  procedure 
or  major  section  of  pool  data. 


/ 


/ 


/ 


/  / 

/ 

/ 


NEXT  Instructs  the  system  to  / 

SEQUENCE  "jump  forward"  to  the  next 
major  node  in  the  pre-  • 
established  sequence,  skipping 
any  intermediate  frames.  If 
in  procedures,  operates  only 
from  major  node-to-node. 

If  in  pool,  operates  from 
any  frame  to  the  next  node. 

REPEAT  Instructs  the  system  to  "jump  / 

SEQUENCE  back"  to  the  last  major  node 
in  the  ordered  sequence 
(e.g.,  a  decision  point  or 
beginning  of  a  procedure) . 

Repeated  use  will  get  back  to 
the  beginning  of  a  procedure 
but  no  further. 
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Table  3-3  (Continued) 


Control 

Group 

CONTROL 
(con' t. ) 


SCREEN 


Mode  of  Use 


Key  Function 

RETURN  Instructs  the  system  to 

display  the  last  previous 
track  (non-pool)  frame  from 
an  associated  pool  item. 

Instructs  the  system  to 
display  the  last  previous 
track  or  pool  frame  from: 

a.  Options  list 

b.  Users'  guide 

c .  Review  mode 

LIST  Instructs  the  system  to 

OPTIONS  display  the  menu  of  alter¬ 

native  data  (track  and 
pool)  associated  with  the 
frame  being  displayed, 
including  changing  tracks. 
User  may  choose  from  the 
menu  or  RETURN. 


USER  Instructs  the  system  to  go 

REQUEST  to  the  user  request  mode 
in  preparation  for  a  user 
request.  System  goes  back 
to  standard  mode  after  the 
request  is  processed,  or 
CLEAR  is  pressed. 

LARGER  Increases  the  size  of  a 

displayed  graphic  one  step 
with  each  key  press.  Only 
affects  contents  of  an 
illustration  window. 


SMALLER  Decreases  the  size  of  a 
displayed  graphic  one 
step  with  each  key  press. 
Only  affects  contents  of 
an  illustration  window. 


User 

Standard  Request  Review 

/ 


✓ 

✓ 

/ 

✓ 


✓ 


/ 


/  /  ✓ 


/  /  ✓ 


Table  3-3  (Continued) 


Mode  of  Use 


Control 
IGouj  ■ 

Key 

Fund:  ion 

Standard 

User 

Request 

SCREEN 
(c  ot,  '  ‘  ) 

i  IT 

*  pu  1WN 

j  left 

►  RIGHT 

Moves  a  displayed  graphic 
i  r.  the  direction  of  the 
ai row.  Each  kev  press 
moves  the  graphic  a 
p  ^  oy i ammed  i  s  ic  r ement . 

Only  affects  contents 
of  an  illustration  window. 

✓ 

✓ 

RESET 

Returns  the  displayed 
graphic  to  the  size  and/or 
position  in  which  it  was 
initially  displayed. 

/ 

V 

✓ 

MEMORY 

HOLD  1 
HOLD  2 

HOLD  3 

Stores  a  copy  of  the  frame 
presently  being  displayed 
in  a  memory  file  (1,  2,  or  3). 
If  the  selected  memory  file 
is  already  filled,  the  new 
copy  will  replace  the  old 
copy. 

/ 

SHOW  1 

SHOW  2 
SHOW  3 

Displays  the  frame  copy  that 
was  prev. ously  stored  in  the 
selected  memory  file.  All 
functions  in  the  SCREEN  group 
above  are  usable  with  respect 
to  the  frame,  but  no  others, 
since  the  system  is  not 
actual ly  at  that  place  in 
the  data  base. 

/ 

/ 

RELE  TSE 

FROM 

SHOW 

Displays  the  last  non-memory 
frame  from  which  a  SHOW 
command  was  initiated. 

/ 

/ 

1  NIC  r 

A  -  Z 

Inputs  alphabetic  characters 

A  through  Z.  Accepted  by 
system  when  followed  by  ENTER. 

V 

/ 

Characters  Y  and  N  input  YES 
and  NO,  respectively,  in 
response  to  displayed  prompts 
only.  Accepted  by  system 

✓ 

when  followed  by  ENTER. 


Review 


/ 


Table  3-3  (Continued) 


Control 

Group 


INPUT 
(con ' t. ) 


hi  a  re 
Keys; 


Mode  of  Use 


User 

Key  Function  Standard  Request 

0-9  Inputs  numerals  0  (zero)  /  v 

through  9.  Accepted  by 
system  when  followed  by 
ENTER. 


-  DASH  Inputs  special  symbols  and  / 

/  SLASH  punctuation  needed  for  forming 
.  PERIOD,  alphanumeric  strings.  Accepted 
DECIMAL  by  system  when  followed  by 
ENTER. 

SPACE  Inputs  one  character  space  J 

needed  in  forming  alphanumeric 
character  strings.  Accepted 
by  system  when  followed  by 
FNTE?.. 


BACK  Backs  the  input  cursor  one  / 

SPACE  character  space  and  erases 

any  input  in  that  space. 

Used  for  making  corrections 
to  alphanumeric  strings 
which  have  been  input. 

Repeated  presses  will  erase 
the  entire  string  but  will 
not  change  mode. 

CLEAR  Erases  all  presently  / 

displayed  input  characters. 


Deletes  USER  REQUEST 
instruction  and  returns 
user  to  the  standard  mode. 

ENTER  Finalizes  the  alphanumeric  / 

input,  allowing  the  system 
to  respond  to  the  information 
keyed  in.  Required  for  all 
INPUT  group  key  actions  except 
BACK  SPACE  and  CLEAR. 


Provisions  have  been  made  for 
six  spare  function  keys  and 
three  spare  input  keys. 


/ 


/ 


/ 


V 


Review 


3.6  FUNCTIONAL  INTERACTION  MODES 


The  automated  delivery  system,  and  the  control  unit,  has  three 
nodes  of  interaction-.  standard,  user  request,  and  review.  All 
three  modes  are  controlled  from  the  control  unit.  The  standard 
mode  uses  ail  portions  of  the  control  panel.  The  user  request 
node  uses  only  the  INPUT  portion  of  the  panel.  The  review  mode 
does  not  use  the  INpUT  portion. 

3.6.1  Standard  Mode- 

This  functional  moue  uses  the  TOC/PROC  model  to  define  the 
commands  available  to  the  user  at  any  particular  time.  Many 
commands  are  initiated  via  single— press  function  keys  located  in 
the  control  group. 

The  standard  mode  of  interaction  is  also  referred  to  as  the 
TOC-Pl-’.OC  mode  since  the  primary  method  of  accessing  a  particular 
portion  of  the  data  base  is  through  selection  from  hierarchical 
tables  of  content  (TOC)  to  reach  the  procedure  (PROC)  or  other 
information  that  is  wanted.  User  interactions  with  the  control 
unit  are  fairly  simple,  and  are  in  response  to  the  prompts  that 
appear  on  each  frame.  Choices  are  principally  to  advance  to  the 
next  frame  in  a  linear  sequence,  binary  (yes-no)  decisions,  and 
selection  from  limited  menus  and  options  lists. 

The-  limited  use  of  the  alphanumeric  keypad  is  to  respond  to 
system-initiated  questions.  These  include:  (a)  indicating  a 
selection  from  a  TOC,  an  options  list,  or  a  pool  menu; 

(b)  choosing  a  path  in  the  text  as  required  by  the  displayed 
frame  (e.g.,  Yes/No);  and  (c)  entering  a  user  identification 
name  or  numbi  i .  The  standard  node  is  the  primary  mode  of  use 
for  technicians,  especially  when  they  are  new  to  the  system, 
and  will  prevail  unless  user  actions  put  the  system  in  one  of 
the  other  two  modes. 
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The  descriptions  of  the  REVERSE  and  REPEAT  SEQUENCE  functions 
contained  in  Table  3-3  require  further  explanation.  If  the  user 
has  passed  through  a  particular  portion  of  the  data  base,  e.g.,  a 
procedure,  in  the  standard  mode,  use  of  these  keys  will  permit 
retracing  the  sequence  in  reverse  order.  If,  however,  the  user 
has  entered  that  portion  of  the  data  base  somewhere  in  the  middle 
via  the  user  request  mode,  there  is  no  path  to  retrace.  In  such 
a  case,  the  use  of  REVERSE  and  REPEAT  SEQUENCE  will  trace  in 
reverse  order  the  sequence  established  by  the  page  sequence 
numbering  scheme  described  in  paragraph  3.8.6. 

3.6.2  User  Request  Mode 

This  functional  mode  increases  the  flexibility  a  technician  has 
to  move  about  in  the  automated  data  base.  It  is  secondary  to 
the  standard  mode  and  should  only  be  used  by  technicians  who  are 
thoroughly  familiar  with  both  the  automated  delivery  system  and 
the  technical  information  in  the  data  base.  It  is  highly  inter¬ 
active  and  imposes  a  significant  requirement  on  the  memory  of 
the  user  (even  though  the  risk  of  getting  lost  or  confused  is 
reduced  through  system  design  and  prompting) .  It  permits  the 
knowledgeable  user  to  "shortcut"  the  TOC-PROC  access  procedure. 
The  system  will  operate  in  the  user  request  mode  only  when  so 
instructed  by  the  using  technician.  When  the  specific  request 
has  been  satisfied,  the  system  reverts  to  the  standard  mode  of 
interaction.  The  user  request  mode  requires  heavy  use  of  the 
alphanumeric  keypad  since  commands  are  initiated  through  alpha¬ 
numeric  character  strings.  Capabilities  include: 

a.  "Jumping"  directly  to  any  part  of  the  data  base  via  a 
frame  index  code  or  a  task  number. 

b.  Entering  allowable  codos/numbers  and  requesting  specific 
associated  information. 

c.  Entering  allowable  codes/numbers  and  obta. ning  a  menu 
of  information  items  associated  with  the  code/number. 


The  allowable  codcs/numbers  referred  to  above  include  data 
such  as  part  numbers,  reference  designators,  and  MIDAS  codes. 
Those  are  toi  nit  d  Input  qualifiers,  output  qualifiers,  and 
content  j  den  L  ’  f  i  r ,  as  described  in  paragraph  3.6.4.  All  user 
request  mode  functions  ax  a  accomplished  in  a  similar  manner. 

The  sc aue nee  of  event  s  ir: 

a.  Pr  USi  R  !’  'Q-'i  :-:'t  fun  it:  vn  key  (in  either  standard  or 
v c view  mode; . 

b.  CRT  displays  user  request  mode  prompt. 

c  Key  in  an  alphanumeric  character  string, 
d.  Press  EhTER. 

t .  System  returns  to  standard  mode  when  requested  data  are 
di  splayed. 

3  .  t .  ?•  Review  Mode 

This  functional  mode  provides  a  basis  for  technician  review 
of  the  technical  data  base  for  purposes  of  familiarization  or 

train ing . 

In  this  mode,  the  system  becomes  a  page  turner  and  the  frames 
■ji'  presented  in  a  predetermined  order.  The  technician,  or  other 
no.',  can  select  this  mode  of  interaction  from  (and  only  from) 
any  options  list.  The  system  will  remain  in  the  review  mode 
until  instructed  to  return  to  the  point  in  the  data  base  where 
the  originating  options  list  was  selected  by  the  technician. 
Frames  presented  in  the  review  mode  will  carry  a  prominent  feed¬ 
back  message  instead  of  the  normal  prompt.  Theoretically,  a 
technician  could  page  through  all  of  the  frames  in  a  TO  in  the 
review  mono  .  Cruet ::  cal  ly ,  it  is  expected  that  the  review  mode 
will  lie  used  mostly  for  reviewing  a  selected  sequence  of 
procedure's  before  beginning  maintenance.  This  mode  may  also 
he  heir. !  ul  for  training,  both  classroom  and  OJT. 


In  the  review  mode  frames  are  presented  in  a  predetermined 
sequence  by  use  of  the  FORWARD  key.  The  user  may  interact  with 
all  function  keys  except  START,  LIST  OPTIONS,  and  HOLD.  All 
keys  in  the  INPUT  group  are  inactive.  Exit  from  the  review  mode 
can  be  accomplished  by  pressing  the  RETURN  or  USER  REQUEST  key, 
to  enter  the  standard  or  user  request  mode,  respectively;  or  by 
pressing  STOP  to  log  off  the  system. 

3.6.4  User  Request  Mode  Interactions 

All  user  request  mode  interactions  require  the  input  of  an 
alphanumeric  character  string  to  convey  to  the  computer  the 
intended  instruction.  Part  of  this  character  string  consists 
of  a  two-letter  mnemonic  that  identifies  the  type  of  input 
being  entered.  In  most  cases,  a  two-letter  mnemonic  at  the 
end  of  the  string  is  also  required,  to  identify  the  type  of 
information  wanted  by  the  user.  Some  mnemonics  are  both  input 
and  output  qualifers,  as  shown  in  Table  3-4.  The  relationship 
between  mnemonics  used  as  user  request  mode  qualifiers  and 
those  used  for  other,  related  purposes  is  depicted  in  Table  3-7, 
later  in  this  section. 

The  alphanumeric  character  string  is  composed  as  follows: 

XX  XXXX....X  XX 
1  2  3  4  5 

1.  The  input  qualifer:  A  two-letter  mnemonic  code  to  qualify 
the  input  string. 

2.  A  space  to  delimit  parts  1  and  3. 

3.  The  content  identifier:  An  alphanumeric  code,  e.g.,  part 
number . 

4.  A  space  to  delimit  parts  3  and  5. 

5.  The  output  qualifier:  A  two-letter  mnemonic  to  qualify 
the  output  desired. 


Table  3-4 

Identification  of  User  Request  Mode  Qualifiers 


Mn«  'non  i  < 


Input 


Output 


A  i  \ 

Au  L orta  to d  As  s i  a  t  ance 

✓ 

V 

CT 

Checkout  Tape  or  Card 

/ 

FC 

Fault  Code 

/ 

/ 

V 

FI 

Fault  Isolation  Procedure 

V 

FN 

Frame  Number 

✓ 

/ 

V 

FH 

Fault  Rcporcing  Procedure 

/ 

V 

GD 

General  Description 

V 

i.;  s 

General  Systems  Manual 

►' 

c/r 

General  Theory  of  Operation 

/ 

GV 

General  Vehicle  Manual 

»/ 

JO 

Job  Guide  (Maintenance) 

✓ 

MC 

MIDAS  Code 

✓ 

/ 

OS 

Gporat i onal  Supplement 

/ 

PL 

Parts  Breakdown,  Illustrated 

/ 

/ 

Pi\ 

Part  Number 

✓ 

/ 

RD 

Reference  Designator 

V 

*' 

00 

S  c  h  err; a  t  .i.  c  D  i  a  r  a  m 

/ 

SR 

Structural  Repair  Manual 

/ 

0  s 

Scj  f  ety  SoppJ  t  tent 

V 

TN 

Task  Number 

>' 

TO 

Tc-chn  j  cal  vi  -a  or 

V 

\ 

WO 

Wiring  Diagram 

/ 

Table  3-5  shows  the  combinations  of  input  and  output  qualifiers 
that  the  automated  delivery  system  will  accept,  and  the  result 
of  each  legitimate  combination.  User  requests  that  involve 
other  combinations  will  generate  an  error  message  on  the  display 
screen.  Likewise,  if  the  content  identifier  character  string 
that  follows  the  input  qualifier  is  not  recognized  by  the 
computer  as  a  valid  combination,  an  error  message  will  be 
presented.  It  is  important  to  note  that,  except  for  input 
qualifier  AA  and  sometimes  TO,  the  input/output  combinations 
are  valid  only  for  data  within  a  specific  TO  in  the  data  base 
within  which  the  technician  is  working  prior  to  initiating  a 
user  request.  The  system  will  not  produce  data  from  other  TOs 
in  the  data  base,  nor  types  of  data  not  contained  in  the  TO. 
However,  while  a  user  is  working  with  a  particular  TO,  information 
from  some  other  TO  can  be  accessed  in  the  user  request  mode  by 
keying  "AA  ###  AA"  to  obtain  the  list  of  TOs  in  the  data  base 
(see  note  5  in  Table  3-5)  ,  or  the  initial  frame  of  another  TO 
can  be  obtained  by  keying  "TO  ###,"  if  the  technician  is  authorizec 
to  use  it. 

3.7  ORGANIZATION  OF  DISPLAY  FRAME  CONTENTS 

3.7.1  Standardization 

One  of  the  objectives  of  the  automated  delivery  system  program, 
is  to  optimize  the  interface  between  the  using  technician  and 
the  presentation  system.  Among  the  factors  to  be  considered  in 
the  satisfaction  of  this  objective  is  the  way  in  which  data  to 
be  presented  are  organized.  To  the  extent  feasible,  a  standard¬ 
ized  organization  should  be  used.  This  will  reduce  search  time 
when  the  technician  is  looking  for  a  particular  type  of  data  or 
information,  and  decrease  the  likelihood  of  essential  information 
being  overlooked.  In  addition,  the  principles  of  standard 
placement  of  designated  information  which  apply  to  paper  TOs 
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To  meet  the  standard  organization  objectives,  all  frames  of 
information,  regardless  of  character  size,  have  three  defined 
areas  in  which  certain  types  of  information  are  always  placed. 
These  are  the  header,  body,  and  prompt,  as  shown  in  Figures  3-4 
and  3-5  for  level  5  and  level  3  character  sizes,  respectively. 
(Note:  Throughout  the  remainder  of  this  report,  examples  of 
data  being  presented  on  the  display  subsystem  are  illustrated 
on  simulated  display  "frames."  These  frames  are  scaled  at 
approximately  38.5%  of  actual  Megatek  screen  size  for  both 
level  5  and  level  3  characters.) 


LINE 


HEADER 

SUBHEAD 


IT  PER 
BODY 


/f 

1 

2 

3 

4 

5 


LOWER 

BODY 


EriOYF? 


34 

35 

36 

37 


Figure  3-4 . 


Organization  of  display  frame  contents 
(level  5  Megatek) . 


LIME 


T'i'iure  3-5.  Organization  of  display  frame  contents 
(level  3  Megatek). 


3.7.2  lit  idea 

first  two  1  j  nes  of  each  frame  comprise  the  header  section. 
The  |>:  ary  header  is  placed  on  the  first  line.  If  the  infor¬ 
mation  on  the  frame  is  part,  of  a  TO,  the  primary  header  consists 
f  the  TV  nurnbei  ,  the  applicable  ."’.IDAS  Code  (if  the  MIDAS  Code 
is  in  u  o.o  and  ap;.2  ies  to  the  information  of  the  frame)  ,  and  the 
f  t  amt  c  Jc.  The  n-  yt  >  ine  ci  the  header  section  is  used  for 
title  nru.:  sub*  i  t  1  r  i  i.  f  o:  p.a  t  ion  ,  and  a  page  sequence  number,  if 
a:  :.-l  j  cable.  If  the  in  forma  t  lor  on  the  frame  is  not  part  of  a 


TO,  the  header  lines  are  used  to  present  equivalent  identifying 
information.  Note  that  the  portions  of  lines  1  and  2  that  are 
at  the  right  margin,  while  technically  part  of  the  header,  will 
change  v;ith  each  frame,  although  the  remainder  of  the  header 
may  remain  constant  through  a  series  of  frames.  Figures  3-6 
and  3-7  illustrate  several  examples  of  header  content.  Guide¬ 
lines  for  preparation  and  placement  of  header  contents  are 
described  in  Subsection  3.8. 


#  ©  INPUT  EITHER  [YES]  OR  [HO]:  [  ];  [ENTER], 


Fxarr.pl  e  of  typical  pool  data  (level  3)  frame. 


> .  '• .  body 

r;  1 1  <;  i  -tt  ion  of  the  frame  begins  on  the  third  line  and  extends 
Lr  the  last  line  preceding  the  prompt  area.  The  first  line  of 
the  body  (third  frame  line)  will  normally  be  left  blank  to 
provide  separation  from  the  header.  The  number  of  lines  included 
in  the  body  will  vary  accordim  to  the  character  size  in  use  for 
the  frame,  as  shown  in  Figures  3-4  and  3-5.  The  body  of  the 
frame  is  considered  to  have  an  upper  portion  and  a  lower  portion 
only  with  respect  to  frames  containing  both  text  and  illustrations 


When  this  occurs,  text  is  always  placed  in  the  upper  body,  and 
illustrations  are  always  placed  in  the  lower  body.  The  decision 
on  the  amount  of  space  to  be  allocated  to  text  versus  illus¬ 
tration  should  be  based  on  the  needs  of  the  user,  and  should 
consider  (when  appropriate)  that  the  illustration  can  be  panned 
and  zoomed  independently  of  other  frame  contents.  When  the  body 
will  contain  only  text  or  only  illustration,  the  complete  body 
area  should  be  used,  as  needed.  Figures  3-6  and  3-7  provide 
representative  examples  of  placement  of  information  in  the  body 
area . 

3.7.4  Prompt 

The  prompt  area  comprises  the  last  three  lines  of  the  frame,  as 
identified  in  Figures  3-4  and  3-5,  although  in  many  cases  only 
the  first  of  these  three  lines  will  be  used  (see  Figures  3-6 
and  3-7).  This  convention  deviates  from  the  principle  that  user 
instructions  should  be  presented  before  the  information  on  which 
a  decision  will  be  based.  Since  the  prompt  information  normally 
deals  only  with  interaction  with  the  system,  standardized 
placement  is  believed  to  be  more  effective  for  the  user,  as  well 
as  to  reduce  programming  complexity  and  data  presentation 
requirements. 

3.8  CODES  ANn  CONVENTIONS 

3.8.1  Overview 

i,.per-hased  Technical  Orders  and  Technical  Manuals  use  many 
techniques  for  coding  and  highlighting  technical  information. 
Some  techniques  are  associated  with  particular  format  types, 
and  some  are  standardized,  e.g.,  for  a  particular  branch  of 
the  military.  Their  purpose  is  to  eliminate,  or  alleviate,  the 
need  for  user  searching  to  find  particular  kinds  of  information. 


to  preclude  overlooking  especially  important  information,  and 
to  provide  redundant  means  of  identifying  certain  data  through 
easily  understood  and  learned  "systems"  of  coding.  The  auto¬ 
mate!  delivery  system  attempts  to  accomplish  the  objectives,  to 
th-.'  extent  feasible,  through  use  of  the  Air  Force  TO  standardized 
codes  and  conventions,  especially  those  that  are  associated  with 
the  formats  adapted  for  use  m  the  system.  In  addition,  advantage 
is  taken  of  the  capabilities  for  computer-generation  and  CRT- 
presentation  of  such  codes  and  conventions.  This  subsection 
describes  the  techniques  recommended  for  achromatic  presen¬ 
tation.  Recommended  techniques  for  the  use  of  color  are 
described  in  Subsection  3.9. 

i  A-  .2  TO  Numbering 

Air  force  TOs  arc  numbered  according  to  an  identification  system 
specified  in  To  0-1-01.  An  automated  delivery  system  must  be 
compatible  with  this  numbering  and  identification  system  if  it 
is  to  be  accepted  for  use  as  part  of  the  Air  Force  Technical 

Order  ( AFTO )  System. 

3.8.2. 1  TOs-  Every  Technical  Order  in  the  AFTO  System  is 
.identified  by  a  unique  TO  number.  The  system  of  number 
identification  has  been  developed  so  that  the  series  of  numbers: 

•  Identifies  the  general  subject  and/or  content  of  the  TO; 

•  Establishes  the  relationship  among  TOs  for  a  particular 
system ; 

•  Provides  sequences  for  filing;  and 

•  Indicates  distribution  requirements. 


3.8. 2. 2  Numbering  of  TOs.  Each  TO  number  is  divided  into 
three  or  more  parts.  Each  part  is  separated  from  the  others  by 
dash;  e.g.,  "00-25-113-F15”  and  "1F-16A-2-32FI-00-1 . " 

a.  The  first  one-  or  two-digit  number  in  the  sequence 
identifies  the  TO  category.  Table  3-6  identifies  the 
categories  of  TOs  encompassed  by  the  AFTO  System.  Numbers 
are  assigned  according  to  equipment  or  commodity  type 
whenever  possible.  Technical  Orders  containing  instructions 
or  procedures  applicable  to  more  than  one  major  group  are 
numbered  in  general  series  for  the  particular  category. 

b.  The  second  and  subsequent  parts  of  the  TO  number  identify 
specific  series,  types,  subcategories,  etc.  of  TOs  within 
the  category.  Meanings  may  be  different  from  one  category 
to  the  next.  Figure  3-8  illustrates  two  examples  of  TO 
numbering,  for  a  general  TO  and  for  a  specific  system  TO. 

A  detailed  explanation  of  TO  numbering  is  contained  in  the 
preface  of  TO  0-1-01.  An  explanation  of  the  numbering  pattern 
used  within  a  category  is  given  in  the  preface  of  the  basic 
Numerical  Index  and  Requirement  Table  (NI&RT)  for  each  category 
of  TOs  listed  in  Table  3-6. 

Certain  TOs,  especially  multi-section  Technical  Manuals  (TMs) , 
are  identified  by  letters  within  the  "individual  publication" 
portion  of  the  TO  number.  Two  different  lettering  systems  are 
used  that,  while  different,  are  fully  compatible.  One  method  is 
given  in  TO  0-1-01;  the  other  is  called  "MIDAS,"  for  Maintenance 
Integrated  Data  Access  System.  In  each  case  where  the  same 
letter  combinations  are  used  by  the  two  systems,  the  meaning 
is  the  same.  Example  2  of  Figure  3-8  shows  an  illustration  of 
letter  code  placement.  Table  3-7  identifies  the  letter  codes 
used  in  hard-copy  TOs,  as  well  as  intended  automated  delivery 
system  applications. 


Table  3-6 

Technical  Order  (TO)  Categories 


TO 

itegc 

0 

00 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 
21 
22 

31 

32 

33 

34 

35 

36 

37 
36 
33 

40 

41 

42 

43 

44 

45 

46 

47 

49 

50 

51 

60 


Title 

Numerical  Index  and  Requirements  Tables.  Numerical  Index,  Alphabetical  indexes,  and  Cross- 

Relerence  Table  Technical  Orders 

Gene'al  Technical  Orders 

Aircraft  Technical  Orders 

Airborne  Engine  Technical  Orders 

Aircraft  Propellers  and  Associated  Equipment  Technical  Orders 
A  -craft  Landing  Gear  Components  and  Associated  Equipment  Technical  Orders 
Airborne  Instrument  Technical  Orders 

Aircraft  and  Missile  Fuel  Systems  and  Equipment  Technical  Orders 

Airborne  Engine  Lubricating  Systems  and  Associated  Equipment  Technical  Orders 

Airborne  E  lectricat  Systems  Technical  Orders 

Airborne  Hydraulic,  Pneumatics  and  Vacuum  Systems  Technical  Orders 
Photographic  Equipment.  Supplies,  and  Sensitized  Materials  Technical  Orders 
Armament  Technical  Orders 
Aubome  Electronic  Equipment  Technical  Orders 

Aircraft  Furnishing  Cargo  Loading  and  Aerial  Delivery,  and  Firefighting  Equipment  Technical  Orders 
Deceleration  Dev.ces,  Personal  and  Survival  Equipment  Technical  Orders 

Aircraft  and  Missile  Temperature  Control,  Pressurizing,  Air  Conditioning,  Heating.  Ice  Eliminating,  and 

Oxygen  Eg  npment  Technical  Orders 

Airborne  Mecnamcal  Equipment  Technical  Orders 

Guidrd  Missue  Technical  Orders 

Aerospace  Technical  Orders 

Ground  Communications- Electronics -Meteorological  (CEM)  Technical  Orders 

Standard  and  Special  Tools  Technical  Orders 

General  Purpose  Test  and  Associated  Equipment  Technical  Orders 

Shop  Machinery  and  Associated  Equipment  Technical  Orders 

Ground  Handling.  Support  ana  Base  Operating  Equipment  Technicel  Orders 

Vehicles  Construction  and  Materials  Handling  Equipment  end  Equipment  end  Components  Technical 

Orders 

Fuel  O'l.  Propellant  Handling  and  Associated  Equipment  Technical  Orders 
Nun  Aeronautical  Engines  and  Components  Technical  Orders 
Wateicraft  and  Associated  Equipment  Technical  Orders 

Commercial  An  Conditioning,  Heating,  Plumbing,  Refrigerating.  Ventilating,  and  Water  Treating 
Equ  pmen:  Technical  Orders 

Subs  sience  and  Food  Se'vice  Equipment  Technical  Orders 

Chemcai,  Oxygen.  Metal  Textile.  Fuels  Cordage.  Lumber,  and  Rubber  Materials  (Dopes  Cleaning 

Compounds.  Glues,  Gases.  Lubi  icants  Paints,  Plastics,  and  so  forth)  Technical  Orders 

Simulators.  Training  Devices,  and  Associated  Equipment  Technical  Orders 

Common  Hardware  Equipment  Technical  Orders 

Railroad  and  Associated  Equipment  Technical  Orders 

Office  Dup  icatmg  Pnntmg  and  Bmdmg  Equipment  Technical  Orders 

Ag-  ic  i. hura1  E  qmpment  T echmcal  Orders 

Opnca'  Instruments,  Timekeeping,  and  Navigation  Equipment  Technical  Orders 
Soecia'  Service  Equipment  Techmca1  Orders 

General  Purpose  Automatic  Test  Systems  (GPATS)  and  Versatile  Automatic  Test  Systems  IVATES' 
Technical  Orders 

Explosive  O'dnance  Disposal  Technical  Orders 


free :  AFHP.L-TF-80-60  ,  Table  2-1 
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Example  #1 :  Numbering  of  General  Technical  Orders 

- General  Technical  Orders 

- Miscellaneous  TOi  ■  General 

- Critical  Alloy  and  Precious 

Metal  Pam  Lilt 

| —  F  -  IS  Series  Aircraft 

TO  00  -  35  -  113  -  FIS 

TO  Category - 1 

TO  Series  - - 

Individual  Publication - - - - 

Specific  Aircraft _ _ 


Example  #2:  Numbering  of  a  Specific  System  TO 


TO 


IF  -  16A  -  2  -  32FI 


"Aircraft  Technical  Orders 
Fighter  Aircraft 

- Model  F  •  16  Aircraft.  Series  A 

- Organizational  Maintenance 

Landing  Gear  System 

- Fault  Isolation 

- General 

I - First  Volume 


TO  Category 
TO  Series  — 


Maintenance  Level 


00  -  1 


Individual  Publication  (using  MIDAS  system) 


Adapted  from:  AFHRL-TR-80-50 ,  Figure  2-2 
*See  paragraph  3.8.3 


Figure  3-8.  Examples  of  meaning  of  TO  numbers. 


3.8.2. 3  Identification  cl  Model  Changes.  The  assignment  of  a 
new  sei if?  designator  (e.g.,  F16;  F16A)  to  a  model  of  system  or 
equi  i  mont  indicates  a  significant  change  in  configuration.  When 
this  occurs,  a  so1  •; *  separate  TOs  for  the  series  is  usually 
procured. .  K  rer.  th^jgh  these  publications  may  repeat  information 
eo.r.tu  i  ned  in  the  manuals  for  the  previous  series,  presenting  the 
inb  ie.i*  i  v.  in  separate  manuals  makes  it  easier  to  understand  and 
use,  and  simplifies  the  cor.trii  of  classified/restricted  infor¬ 
mation.  It  also  facilitates  the  inclusion  of  the  changes  that 
apply  to  one  series  but  not  the  other. 

In  those  cases  where  the  configuration  change  is  not  significant 
i  no ugh  to  justify  issuance  of  a  separate  TO,  the  technical 
information  is  issued  as  changes/additJ ons  to  the  existing  TO, 
'inese  changes  may  ranee  fr  nr.  new  TO  sections  for  the  new 

c.uif  i.  avion  to  footnote:-  noting  differences.  When  differences 
at:  plentiful,  the  TO  may  include  "Difference  Data  Sheets"  which 
identify  the  variations  that  exist  between  different  configu- 

r at i ons . 

I . .  2  .  5  hmd-or inc  .  In  order  to  maintain  compatibility  with  the 
i dent i f ication  system  uescribed  above,  and  still  reflect 

♦  he  unique  characteristics  of  technical  information  presented  via 
in  . :  t  .tod  del  i  very  system,  certain  modifications  have  been 

v  ado  t  the  TO  numbering  and  identification  convention.  The 
:  r  i  tie  .;•?.!  r-oui  f  lcations  are: 

•  dent  oid,  specif  ic  system  TO  in  the  data  base  as  a  single, 
.::cc  ct  ; '  ml  iced  10.  This  permits  elimination  from  the  TO 

lent  ii  ic  d  icn  nirbci  of  ill  data  that  follow  the  maintenance 
:••••.  ,  <•  d*  i'f  nor  .: !  Tos  that  are  sectional  ized  by  tvpe  of 
■  ■  i  .  stub!  :  i  vbabl  v  retain  that  convention . 


•  Add  "AA"  (for  "automated  assistance")  to  the  TO  number  to 
effectively  identify  it  in  indices  as  a  computer-based  TO. 

In  general  TOs,  this  would  be  added  at  the  end  of  the  full  TO 
number,*  e.g.,  TO  00-25-113-F15-AA.  In  TOs  for  a  specific 
system,  "AA"  is  added  after  the  maintenance  level  code, 
replacing  the  individual  publication  code;  e.g.,  TO 
1F-16A-2-AA. 

While  it  would  appear  that  substantial  information  value  is  lost 
by  deleting  the  individual  publication  part  of  the  TO  number,  it 
is  irrelevant  as  part  of  the  complete,  unsectionalized  TO,  and 
the  same  information  is  provided  on  the  appropriate  frames  of 
data  through  the  use  of  MIDAS  codes  (see  paragraph  3.8.3)  and 
frame  codes  (see  paragraph  3.8.4).  The  numbering  system  will 
retain  the  model/series  designation  convention  described  in 
subparagraph  3. 8. 2. 3  for  top-level  model  changes.  Changes  in 
equipment  model/series  below  the  top  level  will  not  be  reflected 
in  the  TO  number,  but  will  be  presented  as  "mini-TOs"  through  an 
access  pre-selection  method  described  in  Section  4.0. 

3.8.3  MIDAS  Code 

MIDAS  is  an  acronym  for  Maintenance  Integrated  Data  Access 
System,  an  approach  to  organization  of  aircraft  system  TOs  that 
was  developed  in  conjunction  with  the  F-16  aircraft  program. 

MIDAS  is  best  Known  for  the  system  of  alphabetic  and  numeric 
indexing  and  identification  that  is  applied  to  all  portions  of 
the  TO.  The  alphabetic  identification  system  has  been  discussed 
briefly  in  subparagraph  3. 8.2.2  and  is  itemized  in  Table  3-7. 

The  numeric  portion  of  the  MIDAS  identification  system  is 
documented  in  MIL-M-83495,  Appendix  A,  where  it  is  called  the 
system/subsystem/subject  (S/S/S)  numbering  system.  In  MIDAS, 
both  the  alphabetic  and  system-level  numeric  identifiers  are 


Table  3-7 

Ftanuai dized  Mnemonic  Codes 


Applications 


Mnemonic 

Flard-Copy 

Automated 

Code 

Name 

MIDAS 

TO  0-1 -01 

Frame  Codes1 

Qualifiers? 

AA 

Automated  Assistance 

_ 

_ 

AA 

AA 

CL 

Checklist 

CL 

CL 

- 

- 

CT 

Checkout  Tape  or  Card 

- 

CT 

— 

CT 

FC 

Fault  Code 

- 

— 

- 

FC 

FI 

Fault  Isolation  Procedure 

FI 

FI 

FI 

FI 

FN 

F rame  Number 

- 

— 

— 

FN 

FP 

Film  Pack 

— 

FP 

— 

— 

FR 

Fault  Reporting  Procedure 

FR 

- 

- 

FR 

GD 

Genera!  Description 

- 

- 

GD 

GD 

GS 

General  Systems  Manual 

GS 

- 

- 

GS 

GT 

General  Tneory  of  Operation 

- 

- 

GT 

GT 

GV 

General  Vehicle  Manual 

GV 

- 

GV 

- 

JG 

Job  Guide  Manual  (NTS) 

JG 

JG 

JG 

JG 

LC 

Lubrication  Chart 

- 

LC 

- 

- 

MC 

MiDAS  Code 

- 

- 

- 

MC 

OS 

Operational  Supplement 

- 

S 

- 

OS 

PB 

Parts  Breakdown,  Illustrated 

IPB 

- 

PB 

PB 

PN 

Part  Number 

- 

- 

- 

PN 

RD 

Reference  Designator 

- 

- 

- 

RD 

SC 

Sequence  Chart 

- 

SC 

- 

- 

3D 

Schematic  Diagram 

SD 

- 

SD 

SD 

SR 

Structural  Repair  Manual 

SR 

- 

- 

SR 

ss 

Safety  Supplement 

- 

ss 

SS 

SS 

TN 

Task  Number 

- 

- 

- 

TN 

TO 

Technical  Order 

- 

TO 

- 

TO 

VVC 

Work  Card 

- 

WC 

- 

- 

WD 

Wiring  Diagrams 

WD 

- 

WD 

WD 

WS 

Work  Sheets 

— 

WS 

— 

— 

7  of  code  used  in  fram*  number 
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incorporated  in  the  TO  identification  number,  as  shown  in 
Example  #2  of  Figure  3-8.  The  S/S/S  numbering  system  is  used 
throughout  each  TO  to  identify  the  chapter,  section,  and  subject 
(or  function)  to  which  the  data  on  each  page  apply,  and  is 
incorporated  in  a  coding  system  for  fault  reporting  and  fault 
isolation.  Within  each  sectionalized  TO,  pages  dealing  with  a 
particular  subject  (or  function)  have  the  same  S/S/S  number  and 
are  located  together. 

The  MIDAS  S/S/S  numbering  scheme  is  composed  of  three  elements 
of  two  digits  each  separated  by  dashes:  ##-##-##.  The  digits 
in  the  first  element  are  used  in  both  the  MIDAS  approach  to  TO 
numbering  and  in  the  six-digit  indexing  scheme.  The  first  two 
digits  identify  the  aircraft  system,  the  second  two  digits 
identify  the  subsystem  within  a  particular  system  type,  and  the 
third  set  of  two  digits  identifies  the  subject,  or  function, 
within  the  subsystem.  Figure  3-9  provides  an  example  of  the 
derivation  of  the  three  elements  for  particular  systems, 
subsystems,  and  subjects.  It  is  this  three-element,  six-digit 
number  that  is  referred  to  as  the  MIDAS  code  in  this  document. 
Table  3-8  provides  the  standard  system  assignments  for  the  first 
two  digits  of  the  MIDAS  code.  Use  of  these  for  data  prepa¬ 
ration,  and  definitions  for  the  second  and  third  elements  of  the 
code,  should  be  developed  from  the  instructions  in  MIL-M-83495. 

When  the  MIDAS  code  is  used  in  VAMIS  applications,  it  is  placed 
on  the  first  line  of  the  header  (see  Figures  3-4  and  3-5)  of 
every  frame  starting  at  the  frame  center  line.  As  presently 
constructed,  eight  (8)  character  spaces  on  the  line  are  reserved 
for  the  MIDAS  code  (six  numerals  and  two  dashes).  The  MIDAS 
code  S/S/S  numbering  system  may  be  expanded  to  eight  digits  in 
the  future.  The  expansion  may  add  characters  at  the  beginning 
of  the  series,  so  that  equipment  other  than  aircraft  can  use  the 
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Ml  L.-M-83495  (USAF) 
APPENDIX  A 


F7  1ST 

ELEMENT 

SLCOND 

ELEMENT 

THIRD 

ELEMENT 

COVERAGE 

CHAPTEK  (Manual) 
(SYSTEM) 

SECTION 

(SUBSYSTEM) 

SUBJECT 

(FUNCTION) 

26  — 

00  — 

00 

Material  which  is  applicable 
to  the  system  as  a  whole . 

(SYSTEM) 

"Fire 

Protection" 

26  — 

20  — 

00 

Material  which  is  applicable 
to  the  subsystem  as  a  whole. 

(SUBSYSTEM) 

"Extinguishing" 

26  — 

22  — 

(SUB-SUBSYSTEM) 
"Engine  Fire 
Extinguishing " 

00 

Material  which  is  applicable 
to  the  sub-subsystem  as  a 
whole.  This  number  (digit) 
is  assigned  by  the  manu¬ 
facturer. 

26  — 

22  — 

03 

: (Function) 
"Bottles" 

Material  which  is  applicable 
to  a  specific  function  of 
the  sub-subsystem.  Both 
digits  are  assigned  by  the 
manufacturer.  If  they  are 
not  specified  herein. 

N  7:.:  In  cover ina  material  which  is  applicable  to  a  system  as  a  whole,  the 
three  clement  number  shall  be  used.  These  shall  be  the  system  number  followed 

be  "-00-07." 


I.xnnile:  2.1-OO-hO  woul  :  be  used  for  description  and  operation,  troubleshooti nn 

aid  maintenance  jractioes  for  the  rorulete  Air  Conditioning  System. 

Figure  3-?.  Example  of  S/S/S  numbering  in  MIDAS. 
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codes;  oi.  at  the  end  of  the  series,  to  provide  even  more 
specific  subject  (function)  identification.  If  this  happens, 
additional  character  spaces  will  be  required  but  the  code  should 
still  be  centered. 

Placement  oi  the  MIDAS  code  in  this  location  of  the  header  will 
assist  "at-a-ulance"  checking  by  users.  To  avoid  having  the 
MIDAS  code  become  less  detectable,  it  should  be  separated  from 
other  information  on  the  primary  header  line  by  at  least  three 
character  spaces.  If  a  particular  TO  has  a  lengthy  TO  number 
that  .imposes  on  this  separation,  shift  the  MIDAS  code  to  the 
r iqht . 

3.8.4  V r ante  Code  Numbering  System 

The  frame  code  numbering  system  is  based  on  the  requirement  for 
the  user  to  be  able  to  identify  the  specific  "page"  within  the 
TO  for  the  purpose  of  reporting  errors,  need  for  improvement, 
and  similar  types  of  feedback  from  the  user  to  the  preparers  of 
the  data.  Likewise,  the  data  preparers  must  have  some  identifi¬ 
cation  method  (although  it  need  not  be  visible  to  the  data  user) 
t  distinguish  one  frame  of  data  from  any  other.  Ideally,  a 
single  coding  system  should  be  able  to  satisfy  both  of  the  above 
needs  without  compromising  or  degrading  the  solution  to  either, 
rinally,  given  that  some  space  on  the  frame  must  be  allocated  to 
the  frame  "code,"  it  should  be  used  to  impart  useful  information 
to  the  technician,  if  feasible,  about  the  frame  contents. 

The  franc  code  will  always  be  located  in  the  upper  right-hand 
ouncr  of  the  frame,  on  the  first  line,  as  shown  in  Figures  3-4 
and  J-f.  Frame  codes  are  included  in  the  example  frames  in 
I'iuures  3-6  and  3-7.  The  frame  code  will  utilize  a  field  of 
10  character  spaces.  The  code  consists  of  a  series  of  alpha- 
nunci ir  characters  that; 
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•  Provides  a  unique  identification  code  for  each  frame  within 
a  TO; 

•  Identifies  the  change  or  revision  status  of  the  technical 
content  of  that  frame; 

•  Identifies  the  level  of  detail  (i.e.,  "track"  applicability) 
to  which  the  content  should  be/has  been  prepared;  and 

•  Identifies  the  type  of  technical  data  comprising  the  content 

The  sequence  and  definition  of  each  character  space  are  as 
follows : 

Space  #1;  A  numeral  from  1  through  6  designating  the  level  of 
detail  of  the  content  of  the  frame,  as  defined  in  Table  3-9. 
Numerals  7,  8,  9,  and  0  are  reserved  for  future  use  if  this 
factor  is  changed  or  expanded. 


Table  3-9 

Level 

.  of  Detail  Codes  (Character  Space  #1) 

for 

Frame  Code 

CODE 

DESCRIPTION 

1 

= 

Text 

& 

illustration 

applicable 

to 

Track  #1  only. 

2 

= 

Text 

& 

illustration 

applicable 

to 

Track  #2  only. 

3 

= 

Text 

& 

illustration 

applicable 

to 

Track  #3  only. 

4 

= 

Text 

& 

illustration 

applicable 

to 

Tracks  #.l  5.  #2. 

5 

- 

Text 

& 

illustration 

applicable 

to 

Tracks  ((2  &  #3. 

6 

= 

Text 

& 

illustration 

applicable 

to 

Tracks  #1 ,  #2 ,  &  #3 . 

7 

= 

(Reserved) 

8 

(Reserved) 

9 

= 

(Reserved) 

0 

— 

(Reserved) 

Spaces  #2  and  #3:  A  two-letter  mnemonic  that  identifies  the 
type  of  technical  data  comprising  the  content.  The  mnemonics 
will  be  the  same  as  those  used  for  data  access  and  codinn  (see 
Table  3-7)  and  are  based  on  the  MIDAS  code  mnemonics,  as 
modified  for  this  program. 


Space  #4:  A  blank  space  to  separate  the  level  of  detail/type 
of  material  code  from  the  basic  frame  code.  This  space  could  be 
used  for  other  purposes  that  are  not  visible  to  the  user  or 
reserved  for  expansion  of  the  number  of  frames. 

Spaces  #5  through  #9:  A  five-digit  numerical  code  that  provides 
a  unique  identification  ot  the  frame  within  the  TO;  i.e.,  the 
frame  number.  This  will  provide  a  capacity  of  99,999  frames  for 
each  TO  in  the  data  base.  A  block  of  these  codes  should  be 
allocated  to  any  material  that  is  common  to  the  TOs  included 
m  the  data  base,  e.g.,  the  instructions  on  the  use  of  the  TO. 

In  this  program,  frame  numbers  99,001  through  99,999  have  been 
reserved  for  materials  which  are  independent  of  a  specific  TO. 

Space  #10:  An  alphabetic  character  (letter)  to  indicate  the 
change,  or  revision  status,  of  the  frame  content.  The  original 
issue  of  the  frame  will  be  blank;  the  first  change  to  the  frame 
will  be  coded  "A,"  the  next  "B,"  and  so  forth  through  the 
alphabet.  This  will  permit  26  changes  to  the  frame  before  a  new 
frame  number  must  be  assigned,  or  the  TO  is  "reissued."  Note, 
however,  that  authorized  hard-copy  TOs  use  numerals  to  show  the 
change  identification,  so  this  is  a  non-conforming  method.  In 
addition,  see  the  discussion  of  the  change  code  symbol  in  sub- 
paragraph  3.8. 7. 3. 

Figure  3-10  provides  examples  of  various  frame  code  possibilities. 


Frame  Code 

Definition 

• 

3JG 

12345 

Track  #3  non-troubleshooting 
maintenance  procedure,  frame 
#12345,  original  issue. 

• 

6PB 

05678B 

Applicable  to  Tracks  #1,  #2,  and 
#3,  Illustrated  Parts  Breakdown, 
frame  #5678,  Change  B. 

• 

2FI 

34567H 

Track  #2  troubleshooting  pro¬ 
cedure,  frame  #34567,  Change  H. 

• 

6AA 

99002C 

Applicable  to  Tracks  #1,  #2,  and 
#3,  User  Instructions,  frame 
#99002,  Change  C. 

• 

6SD 

12456 

Applicable  to  Tracks  #1,  #2,  and 
#3,  Schematic  Diagrams,  Frame 
#12456,  original  issue. 

Figure  3-10.  Example  of  frame  codes. 

Assignment  of  code  entries  will  be  primarily  the  responsibility 
of  the  senior  technical  writer  for  the  TO.  The  codes  for  level 
of  detail  (Space  #1)  and  type  of  material  (Spaces  #2  and  #3) 
should  be  determined  during  task  analysis  but  will  be  applied  by 
the  technical  writer.  The  serial  frame  number  that  uniquely 
identifies  the  frame  (Spaces  #5  through  #9)  can  be  assigned  as 
the  frame  content  is  completed,  from  a  sequential  list  controlled 
by  the  senior  technical  writer,  or  blocks  of  numbers  can  be 
allocated  to  each  individual  technical  writer.  In  either  case, 
accurate  records  must  be  maintained  so  that  frame  codes  are  not 
used  more  than  once  in  a  TO. 

3.8.5  Frame  Titles  and  Subtitles 

Every  frame  in  the  data  base  will  contain  title  information,  at 
some  level,  to  provide  to  the  user  a  description  in  words  of  the 
information  to  follow.  Titles  are  necessary  on  each  frame 


because  of  the  absence  of  a  physical  "package,"  such  as  exists 
in  paper-based  TOs,  and  the  resulting  ease  with  which  a  user  can 
obtain  a  frame  of  information  that  may  be  unrelated  to  the 
immediately  preceding  frame.  Consequently,  each  frame  must 
carry  a  narrative  subject  identification. 

Titles  and,  if  appropriate,  subtitles  are  applied  at  three 
levels.  The  first  level  is  the  title  frame,  wherein  all  or 
most  of  the  frame  is  used  for  title  information.  Title  frames, 
discussed  in  Section  4.0,  are  used  to  precede  a  whole  body  of 
data  and  describe  to  the  user  the  content  of  subsequent  frames 
of  the  package.  Title  frames  are  equivalent  to  the  title  pages 
in  both  sectional ized  and  unsectionalized  paper-based  TOs. 

The  second  level  includes  placement  of  primary  titles  in  the 
header,  on  the  second  line,  and  more  detailed  subtitles  and 
subject  descriptions  on  subsequent  lines.  While  second-level 
titles  will  usually  require  use  of  some  portion  of  the  frame 
body,  as  depicted  in  Figure  3-11,  the  depth  of  description  will 
enable  use  of  third-level  titles  in  all  frames  of  a  series  of 
information  which  follow.  Second-level  titles  should  include 
the  overall  system  name  and,  if  feasible,  the  subsystem  which  is 
the  subject  of  the  series  of  frames.  Subtitles  or  descriptive 
statements  should  explain  the  specific  nature  of  the  frames 
which  are  to  follow,-  e.g..  Bench  Checkout  of  System  XYZ,  Check¬ 
out  No.  123.  Frames  containing  second-level  titles  should  be 
the  first  frame  of  a  series  of  frames  which  all  deal  with  the 
same  subject,  task,  or  function.  The  remainder  of  the  frame 
should  be  used  to  begin  the  presentation  of  that  information; 
e.g.,  the  input  conditions  for  a  particular  maintenance  procedure 


b.  Third-level  frame  title  example. 


r 


’0  1C-141A-?-AA  73- 1 P-D0  5JG  03598D 

4-3:  INPUT  CONDITIONS.  CONTINUED.  ■ 

a  EQUIPMENT  CONDITIONS: 

++4+++++++4++++++++++++++  WARNING  44444444444444444444444444 
THE  FOLLOWING  EQUIPMENT  CONDITIONS  MUST  BE  MET^JIE  FC)£E^ 

US  THE— TAS  K  YO !i_ H A  V F  SFI  Ff-T F 0 


•»  - 
L 


Figure  3-11.  Examples  of  second-level  and  third-level 
frame  titles. 


Most  of  the  frames  in  the  data  base  will  use  third-level  titles. 
A  third-level  title  will  normally  consist  of  a  brief  title  or 
statement  which  deals  specifically  with  the  frame  contents; 
e.g.,  C/O  3-1:  B.  Manual  Ground  Speed  Slew  Check.  This  title 
is  placed  on  the  second  line  of  the  header,  and  should  be 
complete  in  one  line,  leaving  sufficient  space  for  a  "page" 
sequence  number,  if  applicable  (see  paragraph  3.8.6).  If 
additional  explanation  is  necessary,  it  should  be  incorporated 


V 

i 
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in  the  body  of  the  frame  (leaving  the  third  line  blank  whenever 
possible) .  Figures  3-6  and  3-7  illustrated  examples  of  third- 
level  frame  titles. 

3.3.6  " Facie "  Sequence  Number 

"Page”  sequence  numbering  is  used  for  identif ication  of  frames 
of  data  which  are  normally  presented  in  a  certain  sequence  in 
the  standard  mode.  A  maintenance  task,  for  example,  might 
consist  of  10  frames  of  information,  numbered  1  through  10, 
beginning  with  the  input  conditions  frame.  Task  information  of 
this  kind  will  always  be  presented  in  consecutive  order  in  the 
standard  mode.  Similarly,  the  Index  to  Reference  Designations 
in  an  IPB  could  include  several  hundred  consecutively  numbered 
frames  which  could,  if  the  user  prefers,  be  "paged"  through  in 
sequential  order  using  the  FORWARD  key.  Troubleshooting 
procedures  arc  similarly  numbered  for  each  task  since  each 
frame  is  part  of  a  discrete,  identifiable  set  of  information, 
even  though  choices  at  the  decision  points  in  the  logic  tree  may 
result  in  skipping  frames. 

As  shown  in  Figures  3-4  and  3-5,  and  further  illustrated  in 
Figures  3-6  and  3-11,  the  page  sequence  number  is  right-hand 
justified  on  the  second  line  of  the  header.  The  first  frame 
of  the  series  is  always  numbered  "1,"  and  will  normally  have  a 
second-level  title  (see  paragraph  3.8.5).  In  series  of  frames 
which  do  not  have  a  natural  sequence  (e.g.,  fault  isolation 
[ rocedures) ,  a  logical  numbering  scheme  should  be  applied.  For 
example,  each  frame  in  an  LTTA  sequence  would  be  numbered 
sequentially  following  a  path  of  acceptable  responses.  The 
numbering  sequence  would  continue  with  the  first  in  that  branch 
resulting  from  a  non-acceptable  response,  and  so  forth.  This 
type  of  numbering  is  illustrated  in  Figure  3-12. 


PROBLEM 

#1 

PROBLEM 

#2 

PROBLEM 
r  #6 

PROBLEM 

06 

PROBLEM 

#3 

PROBLEM 

#4 

NOTE  Number*  in  circles  are  page  sequence  numbers. 


Figure  3-12.  Page  sequence  numbering  for  branching  path 
sequences  in  LTTAs . 


3.8.7  Symbol  Codes 

3. 8. 7.1  General  Approach.  Formats  developed  for  the  automated 
delivery  system  use  symbol  codes,  as  in  paper-based  systems,  as 
a  shorthand  method  of  informing  the  user  of  some  characteristic 
of  the  information  being  presented.  Some  of  the  codes  are  also 
found  in  some  paper-based  systems,  and  some  are  unique  to  the 
computer-based  system.  It  may  not  be  necessary  to  use  all  of 
these*  codes  in  a  particular  system,  but  it  is  important  that  use 


of  co.ks  be  consistent;  i.e.,  the  meaning  is  equivalent  from  one 
TO  to  the  next  in  the  data  base,  and  from  one  automated  TO  to 
another.  In  addition,  the  use  of  symbol  codes  should  be  a 
redundant  method  of  .information  transfer.  The  operation  of  the 
system  should  never  dependent  on  the  technical  writer 
entering  the  correct  symbol ,  or  on  the  user  seeing,  or  under¬ 
stand  i no ,  that  symbol .  For  example,  the  system  must  be 
pi og rammed  to  re spend,  or  not  respond,  to  a  particular  valid 
keyboard  input  whothei  or  not  the  coding  of  the  displayed  data 
indicates  that  it  is,  or  is  rot ,  a  selectable  entry. 

Table  3-10  identifies  the  symbol  codes  which  have  been  defined 
for  use  in  the  baseline  automated  delivery  system  formats.  The 
following  paragraphs  briefly  describe  details  of  their  use.  If 
midi  tionnl  symbol  coder  a >'c  found  to  be  needed  for  a  particular 
sysu.*:  ,  or  type  of  technical  information,  every  effort  should  be 
made  to  ensure  that  the  meaning  is  clear,  there  is  no  conflict 
with  the  standard  codes,  and  the  system  is  capable  of  presenting 
the  symbol  code  so  that  it  is  easily  recognized  by  the  user. 

J . 8 . V . 2  Selectable  Function L  Callout,  or  Menu  Item.  Brackets 
('  ;>  are  used  to  designate  that  some  information  in  the  body 

'  :  the  : rare  or  m  a  prompt  can,  or  should,  be  selected  or  input 
. :  the  keyboard.  In  addition,  it  visibly  sets  off  the  reference 

•i  ca  i  lout  from  other  screen  data.  This  symbol  is  the  most 
r  uU".;-  ’  ••  -ly  used  of  the  symbol  codes,  appearing  at  least  once  in 
•  "•or,  ‘rum-:,  of  data.  Finer  it  is  unique  to  an  interactive 
ryot'..!:,  it  has  no  counterpart  in  paper-based  TOs .  Use  of  brackets 
va-i'.'  with  the  type  of  data  with  which  it  is  associated  and  the 
;  i  5ii.on.ic-  which  is  expected  of  the  user.  In  prompts  and  advisories 
n.a.-e  of  a  k.-yboard  function  key  may  be  contained  within  the 
L:  ict.'  i:  ,  [  EM  IIP  j  or  [FORWARD].  In-text  and  illustration 

c  iljouts  may  show  the  appropriate  selectable  number  or  letter 


Table  3-10 

Symbol  Codes  Used  in  Interactive 

Formats 

Symbol 

Definition 

Reference 

[  ] 

Selectable  function  callout, 
or  menu  item  (key  codes  and 
index  codes) 

Examples : 

[A]  Index  key  "A" 

[23]  Index  keys  "2"  &  "3", 
e.g.,  "23" 

[ENTER]  Function  key  "ENTER" 

Figures  3-5 
3-6 
3-1 

*  * 

Non-selectable  callout 

Examples : 

*2*  *A*  *125*  *f* 

Figure  3-] 5 

# 

Change  in  text  or 
illustration 

Figure  3-6 

\2> 

Question  must  be  answered 
before  proceeding 

Figure-  3-6 

O 

Prompt  or  advisory  on  this 
line 

Figure  3-7 

0 

Numeral  "zero,"  when  not 
otherwise  distinguishable 
from  letter  "0" 

Example : 

T.O.  10P3-ASQ-99 

A 

Notes  and  footnotes  in 
illustrations 

Figure  3-14 

Examples : 

A  A 

Leader  line  for  illustration 
callouts 

Figure  3-1 5 

++++++++ 

Delineates  WARNING  message 

Ficure  3-16 

i  «  «  i  t  «  i  i 

Delineates  CAUTION  message 

Fiuure  3-16 

Delineates  in-text  NOTE 

1 

■  r- 

within  the  brackets/  e.g.,  [B]  or  [23].  In  certain  cases  the 
brackets  may  be  empty.  This  may  occur  in  prompts  to  show  the 
need  for  input  of  a  selection/  e.g.. 


FOR  BREAKDOWN  ILLU 
( F.NTF.R  ]  . 


ON:  INPUT  FIGURE  NUMBER  [  ] ; 


When  the  user  makes  a  selection  on  the  keyboard,  the  number  will 
appear  wi thin  the  LiscKets  of  the  prompt  to  permit  the  user  to 
verify  its  accuracy  torcir.  entering  the  request.  Similarly,  on 
menus  and  lists  empty  brackets  are  placed  at  the  top  of  a  column 
of  iten  designators  to  show  that  all  designators,  unless  other¬ 
wise  coded,  arc  selectable  on  the  keyboard.  This  eliminates  the 
necessity  for  placing  each  menu  designator  within  brackets. 
Figure®  3-6  and  3-7  showed  many  of  the  uses  of  the  bracket 
symbol.  For  other  examples,  see  the  format  samples  in  this  and 
subsequent  sections. 


a.  K<  y  codes  and  _i_r.de x  codes.  Letters,  numbers,  and  words 
appearing  on  the  screen  which  are  selectable  using  the  control 
unit  keyboard  will  be  denoted  by  brackets  ([  ]).  When  these 

appear  in  the  text  or  in  prompts,  or  as  callouts  in  illus¬ 
trations,  the  brackets  will  enclose  the  code,-  e.g.,  [2],  [A], 

|3B],  [FORWARD].  The  right-hand  bracket  will  always  be  followed 
i.y  e:  ther  a  blank  space  or  normal  punctuation.  When  codes  are 
used  in  column  format,  as  in  menus  and  lists,  the  brackets  will 
be  placed  at  the  top  of  each  column  of  selectable  codes  to 
denote  that  all  codes  in  the  column  are  selectable  unless 
otherwise  codec.  Preferred  practice  is  to  place  the  brackets 
immediate! y  beneath  the  column  title;  e.g.,  INDEX  or  KEY. 

13  [  ] 

Ti:  instances  where  space  i a  problem  and  the  placement  of 
bt arrets  would  require  use  of  a  line  which  will  be  blank  other¬ 
wise,  the  brackets  may  enclose  the  column  title;  e.g.,  [INDEX] 

.!  [KEY;  .  Tins  us  an-,  should  be  avoided  to  the  extent  possible 
s.r.ce  there-  are  no  keys  on  the  control  unit  with  these  names. 
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b.  Key  code  and  index  code  content.  Codes  may  consist  of  one 
or  more  number  or  letter  characters,  separately  or  in  combi¬ 
nation.  Whenever  possible,  use  an  already  available  code/ 
e.g.,  in  IPBs  use  the  index  number  as  the  index  code.  When 
there  are  no  constraints  based  on  other  frame  contents,  follow 
these  preferential  usage  rules: 

•  When  a  column  will  contain  fewer  than  ten  (10)  codes,  use 
single-digit  numbers. 

•  When  a  column  will  contain  from  ten  (10)  to  twenty-six  (26) 
codes,  use  single-digit  letters. 

•  When  a  column,  or  multiple  columns  in  the  same  frame,  will 
exceed  twenty-six  (26)  codes,  use  multi-digit  numbers. 

•  When  two  (2)  different  columns  are  needed  on  the  same 
frame  (to  select  different  kinds  of  data  from  the  same  line 
description) ,  title  one  column  "INDEX"  and  use  number-based 
codes.  Title  the  other  "KEY"  and  use  letter-based  codes. 

When  a  number-based  code  requires  further  definition,  e.g.,  if 
there  are  three  options  for  the  same  index  number,  use  letter 
suffixes  and/or  prefixes:  7A,  7B,  7C  or  AP3 ,  AP4 ,  AP5 . 

Suffixes  should  be  used  in  preference  to  prefixes.  In  a  column 
of  letter-based  codes,  suffix  and/or  prefix  numbers  may  also  be 
used. 

c.  Non-selectable  codes.  When  it  is  necessary  for  text  or 
lists  to  include  codes  that  are  not  selectable,  but  which  may 
be  confused  with  those  that  are  selectable,  the  code  should  be 
preceded  and  followed  by  asterisks  rather  than  brackets  (see 
subparagraph  3. 8. 7. 3). 


d.  Columns  of  codes.  The  width  of  columns  of  index  codes 
and  key  codes  will  depend  on  content.  The  minimum  width  in 
all  cases  will  be  two  (2)  character  spaces,  one  for  a  code 
character  followed  by  at  least  one  blank  space.  The  maximum 
width  will  normally  not  exceed  six  (6)  spaces,  comprising  five 
(5)  alphanumeric  characters  and  one  (1)  blank  space. 

e.  Column  justification.  When  a  column  of  codes  is  either 

all  numeric  or  all  alphabetic,  the  column  should  be  right-hand 

justified.  When  a  column  of  codes  contains  both  numerics  and 

alphabetics,  whether  as  basic  codes  or  as  suffixes,  the  column 

should  be  justified  on  the  "units"  of  the  numeric  codes. 

Alphabetic  codes  and  letter  suffixes  to  numeric  codes  will  be 

in  the  column  which  follows  the  justification  column.  In  the 

event  that  alpha  codes  in  a  mixed  column  require  more  than  one 

character,  e.g.,  AA,  AB,  the  last  letter  of  the  alpha  code  will 

be  placed  in  the  space  following  the  justification  column,  with 

the  code  extending  to  the  left.  Example:  98 

99A 

99B 

100 

Z 

101 

AA 

BB 

1.8. 7. 3  Non-Selectable  Callout.  Double  asterisks  (*  *)  are 
used  to  designate  that  a  particular  callout  or  reference  which 
appears  in  the  text  or  illustration  is  not  selectable  on  the 
keyboard.  As  with  the  brackets  used  for  indicating  that  the 
callout  i^s  selectable,  the  symbols  help  to  designate,  or 
net  off,  the  reference  or  callout,  e.g.,  *123*,  to  assist  in 
distinguishing  between  the  callout  and  other  letters  or  numbers 
which  may  appear  on  the  frame,  e.g.,  values.  Asterisk  symbols 
are  shown  in  Figures  3-6  and  3-7.  The  code  should  always  be 


used  when  space  permits,  and  is  especially  important  if  the  user 
could  be  confused  about  which  callouts  are  selectable  and  which 
are  not.  On  some  complex  diagrams  and  illustrations,  where 
adding  the  codes  to  the  callouts  would  significantly  degrade  the 
quality  of  the  illustration,  other  methods  of  clarifying  the 
issue  will  be  needed. 

Two  notes  are  in  order  regarding  the  use  of  asterisks  as  a 
symbol  code.  The  first  is  that  asterisks  are  sometimes  used  in 
both  text  and  illustrations  of  paper-based  systems  to  reference 
a  note  or  footnote.  Since  this  practice  is  not  intended,  or 
necessary,  in  an  automated  delivery  system,  and  footnote 
asterisks  are  not  "paired"  with  a  callout,  the  use  of  these 
codes  should  not  represent  a  conflict  with  other  uses.  The 
second  consideration  is  the  style,  and  size,  of  the  symbol.  The 
asterisks  used  in  the  examples  in  this  document  are  5-pointed, 
e.g.,  *.  This  choice  was  partly  one  of  convenience,  and  partly 
because  a  5-pointed  asterisk  is  more  easily  resolvable  by  the 
eye  than  is  the  6-pointed  asterisk,  e.g.,  *  ,  of  the  same  size. 
Some  displays,  however,  may  use  a  6-pointed  asterisk  as  a 
standard  character,  and  some  may  more  economically  use  6-pointed 
asterisks.  In  a  vector-type  display,  for  instance,  a  5-pointed 
asterisk  requires  five  vectors  to  "draw"  it,  while  a  6-pointed 
asterisk  requires  only  three  vectors.  If  it  appears  that  a 
6-pointed  astcrisK  should  be  used,  the  size  of  the  symbol  may 
need  to  be  increased  in  order  to  enhance  discrimination. 

3. 8. 7. 4  Change  in  Text  or  Illustration.  The  symbol  "#"  is  used 
for  a  marginal  indication  that  some  portion  of  the  data  on  that 
line  has  been  changed,  including  additions  and  deletions.  The 
symbol  is  placed  in  the  left  marginal  space,  outside  of  the 
defined  area  or  (in  multi-column  formats)  in  the  space  between 
columns  to  the  left  of  the  affected  entry.  Specifications  for 


preparation  of  paper-based  TOs  generally  require  some  indication 
(vertical  bars,  etc.)  of  the  location  of  the  changes  on  revision 
pages,  and  this  symbol  serves  the  same  purpose.  (Also  see 
discussion  at  paragraph  3.8.4  regarding  the  use  of  the  frame 
code  for  indicating  revision  status  of  the  frame.) 

Change  coding  requirements  have  sometimes  been  challenged  on 
the  grounds  that  the  fact  of  a  change  is  irrelevant,  since  USAF 
technicians  arc  required  to  perform  maintenance,  etc.  in 
accordance  with  the  TO,  and  not  from  memory.  A  technician  who 
has  never  performed  maintenance  with  a  procedure  showing  that  a 
particular  passage  has  been  changed  will  derive  little  benefit 
from  the  information,  whether  in  hard  copy  or  on  a  video  screen. 
On  the  other  hand,  technicians  who  have  performed  a  task 
repeatedly  over  a  period  of  time  may  continue  to  perform  it  that 
way  without  realizing  that  it  has  been  changed  if  some  method  of 
emphasizing  the  change  is  not  used.  Change  marking  also  facili¬ 
tates  a  review  of  differences  when  new  "change  pages"  are  being 
placed  in  paper  TOs. 

The  value  of  change  marking  in  an  interactive  system  of  the 
baseline  conf iguration  may  be  both  more  and  less  significant 
than  in  a  paper-based  system.  Systems  which  provide  for 
automatic  (as  far  as  the  user  is  concerned)  update  and  cor¬ 
rection  of  the  data  base  make  it  difficult  for  the  user  to  know 
c>f  ,  much  less  compare,  the  changes  from  the  earlier  data  unless 
some  emphasis  is  marked.  Conversely,  automatic  update  of 
technical  data  may  (and  should)  result  in  much  more  frequent  and 
timely  correction  of  data,  but  only  the  last  change  will  be 
noted  on  the  frame.  In  addition,  while  paper-based  TOs  have 
marginal  space  to  spare,  video  screens  have  very  little,  and 
some  systems  may  have  none  in  which  characters  or  symbols  can  be 
displayed.  This  would  require  use  of  valuable  content  area,  and 
further  degrade  the  presentation  of  useful  and  necessary 
i  r.  formation . 
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As  long  as  change  marking  of  TOs  is  required,  the  method 
presented  here  is  recommended  as  being  the  simplest  and  contri¬ 
buting  the  least  amount  of  distracting  clutter  on  the  screen. 
Alternate  methods  such  as  highlighting  changes  only  on  demand 
through  a  keyboard  input  may  be  feasible  in  the  future. 


3.8. 7. 5  Prompt  and  Question  Markers.  These  two  codes  are 
discussed  together  since  the  same  basic  symbol  is  used  for 


both: 


.  The  marker  is  placed  at  the  left  margin  of  the 
content  area  and  points  to  a  prompt  to  the  user,  or  a  question 
which  must  be  answered  before  the  user  can  obtain  the  appro¬ 
priate  next  frame.  A  question  mark  is  placed  in  the  symbol, 
e.g.,  ,  to  denote  such  a  question.  The  symbol  preceding 

the  related  prompt  at  the  bottom  of  the  frame  will  also  include 
the  question  mark.  If  a  user  attempts  to  bypass  making  a  choice 
(e.g.,  YES  or  NO),  the  system  should  either: 


•  Default  to  a  neutral  frame,  such  as  an  options  list,  or 

•  Present  an  advisory  error  message  with  instructions  for 
making  a  choice. 

The  question  symbol  is  used  only  for  questions  where  a  choice 
must  be  made,  either  to  instruct  the  system  on  which  next  frame 
is  needed  based  on  results  found  during  performance  of  a  task 
(see  Figure  3-6) ,  or  to  prevent  the  technician  from  continuing 
a  maintenance  procedure  without  at  least  acknowledging  the 
potential  existence  of  a  hazardous  condition  (see  Figure  3-13) . 
Both  of  these  possibilities  are  further  illustrated  in  the 
format  samples  and  guidelines  in  later  sections.  In  addition, 
specialized  variations  on  the  use  of  the  prompt/question  symbol 
are  described  and  illustrated  in  Section  8.0  in  connection  with 
the  discussion  of  Track  2  LTTAs .  When  the  nature  of  the  prompt 
is  routine,  the  question  mark  is  omitted  from  the  prompt  symbol, 
as  shown  in  Figure  3-7. 


t  TO  1C-14IA-2-AA  73-10-00 

#  4-3:  INPUT  CONDITIONS,  CONTINUED. 

•  EQUIPMENT  CONDITIONS: 


5JG  03598D 


WARNING  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  -M--4- 
THE  FOLLOWING  EQUIPMENT  CONDITIONS  MUST  BE  MET  BEFORE 
DOING  THE  TASK  YOU  HAVE  SELECTED. 

4444-4.4444444444-4-4-44444  +  +  +  4  +  4+++  +  +  +  +  +  '4-  +  4  +  +  +  +  +  +  4-  +  '»  +  +  +  +  +  +  4-  +  +  +  *  + 

-  HAS  FUEL  FROM  TANAS  BEEN  SHUT  OFF  FOR  APPLICABLE  ENGINE 
AS  SHOWN  BY: 

0  -  FIRE  EMERGENCY  HANDLE  *1*  PULLED  AND  TAGGED? 

*  0  -  ENGINE  FIRE  EXTINGUISHER  CIRCUIT  BREAKER  *2*  OPEN  AND 
P  TAGGED?  ^ 


#  rT)  ape  both  CONDITIONS  VERIFIED?  INPUT  [US]  OR  [NO]  [  ]; 

.  [ENTEP], 


Figure  3-13.  Exarr.ple  of  use  of  question  marker  symbols 
for  hazardous  condition  verification. 


J.8.7.0  numeral  Zero.  The  characters  representing  the  letter 
"o"  and  the  number  "0”  (zero)  are  frequently  so  similar,  if  not 
identical,  that  readers  cannot  tell  the  difference.  Ordinarily, 
when  the  character  is  in  context,  there  is  no  problem.  Often, 
howevei  ,  the  context  is  not  apparent  or  does  not  help.  Because 
of  this  it  is  necessary  to  be  able  to  discriminate  between  the 
two  characters.  For  purposes  of  standardization,  the  method  for 
providing  discrimi nabi 1 ity  should  be  applied  throughout  the  data 
base,  not  just  when  the  writer  believes  that  confusion  miaht 


result.  The  preferred  solution,  obviously,  is  to  use  characters 
with  different  characteristics  that  are  easily  recognizable  as 
the  letter  or  number  they  represent.  The  character  sets  which 
are  standard  for  many  displays  have  zeros  and  Os  which  are 
different  and,  with  use,  become  recognized  as  the  number  or 
letter  without  confusion.  However,  when  such  discrimination  is 
not  readily  available,  one  of  the  characters  should  be  altered. 
The  practice  followed  in  these  guidelines  is  to  place  a  slash 
mark  through  the  number  zero  (0) .  This  is  the  recommended 
approach. 

3. 8. 7. 7  Notes  and  Footnotes  in  Illustrations.  The  graphics  and 
legends  which  make  up  an  illustration  cannot  always  provide  a 
completely  clear  representation  of  configuration  or  other 
characteristics.  Common  practice  is  to  provide  a  note,  usually 
referenced  by  a  number  or  letter  placed  in  a  circle,  box,  or 
triangle.  The  standard  approach  used  in  these  samples  is  the 
number  and  triangle:  A  .  Care  should  be  exercised  in  the  use 
of  notes.  In  hard-copy  illustrations  such  notes  are  often  used 
to  reference  differences  in  configuration  between  various  series 
or  models  of  equipment.  In  a  computer-based  system  each  configu 
ration  should  be  represented  independently,  with  appropriate 
identification,  as  part  of  the  mini-TO  concept.  Notes  should  be 
reserved  for  circumstances  which  cannot  be  shown  graphically, 

or  to  provide  a  reference  to  related  configuration  illustrations 
etc.  Figure  3-14  provides  an  example  of  the  use  of  notes  in 
drawings  and  illustrations. 

3. 8. 7. 8  Leader  Lines  for  Illustrations.  Many  variations  of 

leader  lines  to  connect  a  callout  to  a  particular  component  or 
characteristic  are  used  in  TO  drawings  and  illustrations.  The 
preferred  practice  for  automated  applications  is  a  single, 
straight  line  with  a  filled  arrowhead:  ^  .  The  use  of  the 


arrowhead  to  point  to  the  component  is  recommended  to  aid  in 
determining  where  the  leader  line  ends,  since  this  is  often 
a  problem  in  detailed  drawings  and  may  be  particularly  so  in 
computer-generated  video  displays.  Leader  lines  should  never 
cross,  and  should  consist  of  a  single  straight  line  whenever 
possible.  Figure  3-15  depicts  several  examples  of  the  use  of 
this  symbol. 
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Fiaure  3-15. 


Examples  of  the  use  of  leader  lines  in 
illustration  callouts. 


3.8.8  Warnings,  Cautions,  and  Notes 

A PTC  specifications  are  fairly  consistent  in  requiring  special 
attention  to  the  manner  in  which  warnings,  cautions,  and  notes 
are  displayed  on  the  pages  of  paper-based  TOs.  Military 
Specification  M1L-M -18784  provides  the  basic  requirements  to 
the  extent  that  technical  content  specifications  do  not  provide 
specific  requirements.  M1L-M-38 /84A  defines  these  three  types 
of  data  as  follows: 

•  Warning:  An  operating  or  maintenance  procedure,  practice, 
condition,  statement,  etc.,  which,  if  not  strictly  observed, 
could  result  in  iaiury  to  or  death  of  personnel. 

•  '.'action:  An  operating  or  maintenance  procedure,  practice, 
condition,  statement,  etc.,  which,  if  not  strictly  observed, 
cav.d  result  in  damage  to,  or  destruction  of,  equipment  or 

loss  at  p"  scion  effectiveness. 

•  Note:  An  essential  operating  or  maintenance  procedure, 
condition,  or  statement,  which  must  be  highlighted. 

The  specification  provides  several  acceptable  methods  for 
presenting  warnings,  cautions,  and  notes,  all  of  which  are 
intended  to  draw  attention  to  the  statement  through  high¬ 
lighting,  character  size,  page  layout,  etc. 

he  approach  followed  in  this  baseline  program  is  generally 
c  n:'  ]  stunt  with  the  requirements  of  MIL-M-38784  ,  but  increases 
t he  use  :  f  symbolic  highlighting  and  decreases  the  use  of  page 
;  i factors  which  take  up  added  frame  content  space.  The 
r  ev  m  :■  ended  crime  ar.d  layout  of  warning,  caution,  and  note 
st at  event s  are  illustrated  in  Figure  3-16.  The  symbols  selected 
‘  >r  the  "borders"  fo:  each  statement  type  are  based  on  their 

•  e )  .a.  ■!  v.  "d  relative  value  vr.  attracting  attention  to  the  statement 
!  ut  at  i  datively  little  cost  to  the  graphic  capability  and 
memory  of  the  tester  . 


444444444444444444444444444  WARNING  444444444444444444444444444444 
MAKE  CERTAIN  THAT  ELECTRIC  AND  HYDRAULIC  POWER  IS  OFF.  A  POWERED 
FAN  THAT  BREAKS  LOOSE  WILL  CUT  OR  REMOVE  FINGERS. 

444444444444444444444444444444444444444444444444444444444444444444 

. . . .  "•"•••  CAUTION 

CONNECT  A  6  dB  PAD  (EDISON  800-P3)  AND  AN  INLINE  RF  FUSE  TO  THE 
RF  OUTPUT  OF  THE  SIGNAL  GENERATOR.  ON  LOW  LEVEL  RF  INPUT  RECEIVER 
TESTS,  THE  INLINE  FUSE  MAY  HAVE  TO  BE  REMOVED  TO  ELIMINATE 
INSERTION  LOSS  EFFECTS. 

. . .  •  i  '  *  *  •  *  '  '  '  '  ' 


.  NOTE  . 

UNLESS  OTHERWISE  SPECIFIED,  ALL  TESTS  ARE  TO  BE  CONDUCTED  WITH 
THE  BW  (BANDWIDTH)  SWITCH  IN  THE  WB  (WIDEBAND)  POSITION. 


•  Center  the  title  in  the  frame,  with  one  blank  space  before  and 
after. 

•  Symbols  are  to  extend  from  the  left-hand  margin  to  the  right- 
hand  margin. 

•  Indent  text  one  space  from  the  left-hand  margin  on  all  lines. 

•  Single  line  text  which  is  less  than  one  full  line  should  be 
centered . 

•  Skip  one  line  before  the  top  symbol  line  and  after  the  bottom 
symbol  line  which  delineate  a  warning,  caution,  or  note. 


Figure  3-16.  Conventions  for  warnings,  cautions,  and  notes. 
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Warning  and  caution  statements  should  always  precede  the 
procedural  text  to  which  they  apply,  but  follow  the  header 
information.  Notes  can  either  precede  or  follow  the  text,  but 
should  generally  precede  it.  In  all  cases,  the  border  and 
the  statement  text  should  use  the  full  width  of  the  frame 
content  area.  Figure  3-1'  illustrated  placement  of  a  warning 
statement  on  a  typical  frame  or  information.  Additional 
approaches  to  highlighting  warning  and  caution  statements  are 
discussed  in  paragraph  3 .  h ,  9  and,  for  color-capable  display 
systems,  in  Subsection  3.9.  Note,  however,  that  these  alter¬ 
nates  are  in  addition  to,  not  instead  of,  the  guidance  provided 
here . 


..8.9  H_ighli gh_ti r.g  and  Other  Coding 

3.8.9. 1  General.  Many  other  methods  of  coding  are  available 
lor  u se ,  depending  on  system  capability  and  coding  needs.  These 
include  inverse  video,  brightness  coding,  and  flashing.  These 
methods  are  not  only  more  easily  accomplished  with  a  computer- 
based  video  display  than  in  paper-based  systems,  but  some  are 
no*  possible  in  a  paper-based  manual.  As  is  true  with  the  use 
c !  color,  however,  these  capabilities  can  be  easily  misused,  or 
nerve  no  useful  purpose,  if  they  are  not  based  on  a  specific 
:  <  i  are  not  applied  in  a  consistent  manner.  For  this  program 

'in  ;  allowing  specific  guidance  applies. 

1.  d.  >.  l  Bt  ;  ihtiic  or.  Coding .  In  order  for  this  method  of  coding 
x  v  be  e  :  ecti  ve ,  the  contrast  between  two  brightness  levels  must 
be  *.  .it  enough  to  ensure  detectability  by  the  user.  Not  more 

•  han  l..re e  (and  preferably  not  more  than  two)  different  bright- 

•  <  ss  1 e  tel r  should  be  used  fc  coding.  The  higher  brightness 
:■  sho  lid  always  be  used  for  the  element  to  which  the  user's 
at  ton'.  .  ,;:i  n-  to  be  drawn.  Although  brightness  coding  is  not 

d  j  thin  program,  it  uan.  sometimes  be  used  effectively  for 
u  pi  ,  mf  ions  such  as:  •cV-.'J 


•  Highlighting  a  particular  line  of  text  or  in  a  complex  table 
when  a  cursor  is  used,  to  assist  the  user  in  locating  and 
holding  his  place  on  a  specific  item  of  information. 

•  Highlighting  a  key  code  or  index  code  and  its  related  data 
in  response  to  a  keyboard  input,  to  assist  the  user  in 
verifying  the  selection  accuracy  prior  to  entering  the 
request . 

•  Highlighting  a  feedback  message,  particularly  an  error 
message,  to  draw  the  user's  attention  to  it. 

•  Highlighting  warnings,  cautions,  and  notes  to  further 
promote  user  detection  and  response. 

When  brightness  coding  is  used,  it  should  always  be  accomplished 
by  increasing  the  brightness  of  the  coded  item  rather  than  by 
decreasing  the  brightness  of  the  remaining  data,  causing  the 
latter  to  become  less  legible. 

3. 8. 9. 3  Flashing.  Display  coding  by  means  of  causing  some 
portion  of  the  display  to  flash  on  and  off,  or  "blink,"  with 
different  brightness  levels  is  not  recommended  for  presentations 
of  the  type  being  considered  here  with  one  exception  (see 
paragraph  3.8.10).  Best  use  of  flash  coding  is  for  emergency 
types  of  conditions,  where  the  user  must  take  some  response 
action  rapidly  i "  orde*"  to  avoid  or  remedy  a  hazardous  condition 
This  type  of  use  could  be  appropriate  for  some  types  of  opera¬ 
tional  procedures  presentations,  or  in  some  kinds  of  test 
procedures  where  automated  test  equipment  (ATE)  is  linked  with 
the  automated  display  system,  considerations  not  present  with 
the  baseline  system.  Flashing  should  not  be  used  in  circum¬ 
stances  where  the  flashing  message  could  remain  on  the  screen 
for  a  period  of  time,  such  as  while  a  particular  procedural  step 
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or  task  is  performed,  since  it  then  becomes  distracting  rather 
than  helpful.  The  only  application  for  this  type  of  coding  in 
the  computer-based  system  is  a  blinking  advisory  message  as 
described  in  paragraph  3.8.10.  If  flash  coding  is  otherwise 
used,  it  should  be  reserved  :  r  only  the  most  urgent  warninqs 
ami  ;  lie  system  must  liam  t  hv  .  spaLility  for  canceling  the 
f  la  ailin'.. ,  cither  in  i capon se  to  an  elapsed  period  of  time  or  by 
providinu  the  user  with  J,e  '-.inability  of  acknowledging  the 
ir.-  .-sane  through  the  centre  unit . 

3.  P.9.4  Inverse  Video.  Ceding  by  the  inverse  video  technique 
11. o.,  by  reversing  the  normal  nackground-to-content  relation¬ 
ship,  e.  from  1 iqht  on  dark  to  dark  on  light)  is  one  of  the 
r. .  a t  erfectivc  \  idee-  coding  techniques  when  used  consistently. 

i  is  «•••;  :ect.i  v;  in  both  achromatic  and  color  presentations, 

.. !  though  the  "best”  uses  r.  :.y  be  different  in  the  two  types  of 
bis;,  .ay.  The  auiueiir.es  for  this  program  are  to  use  inverse 
video  only  for  the  standard  prompt  message,  to  draw  attention  to 
the  prompt  while  at  the  same  time  providing  separation  between 
the  pi'  mpt  and  the  rest  of  the  displayed  information.  In  so 
1  rim; ,  if  a  feedback  or  advisory  message  is  displayed  after  the 
prompt,  it  coo  will  be  more  detectable  than  if  it  appears  in  the 
sure  manner  as  the  prompt.  Because  of  the  costs  involved  in 
; : e)  win!  paper-based  materials,  the  samples  which  are  used  to 
illustrate  fort. at  characteristics  throughout  this  document  do 
n  ■!  show  the  prompt  in  inverse  video.  Figures  3-17  and  3-18 
depict  the  use  of  this  coding  technique  for  the  frame  prompt, 
lot  dark-on-light  and  1 ight-cn-dark  normal  presentations, 
r  :  spec  five  2  y  . 

1.8.1  f  J  hior.ufs  in.  i'c-  ih.w.  .vlvisory  Messages 

last  three  lines  of  each  frame  of  data  are  reserved  for 
:  :  o:-.;.  ‘ w. ,  feedback  messages,  and  advisory  messages.  A  particular 
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frame  of  data  will  always  have  at  least  one  prompt,  describing 
to  the  user  what  needs  to  be  done  with  respect  to  the  data 
displayed,  or  to  suggest  probable  alternative  courses  of  action. 
The  convention  is  to  display  the  prompt  in  inverse  video  as 
shown  in  Figures  3-17  and  3-18,  with  each  prompt  preceded  by  a 
pointer.  Prompts  should  be  concise  statements  that  begin  with 
what  is  to  be  done  (or  what  can  be  obtained),  followed  by  the 
means  of  accomplishment.  A  single  prompt  should,  if  possible, 
be  complete  on  one  line.  Only  one  prompt  will  be  needed  for 
most  frames.  As  a  general  rule,  frames  should  not  exceed  two 
prompts,  leaving  the  remaining  space  for  feedback  and  advisory 
messages. 

Feedback  and  advisory  messages  will  only  appear  on  the  screen  in 
response  to  some  action  by  the  user.  Feedback  messages  are  a 
result  of  normal  interaction  with  the  system,  such  as  providing 
the  technician  with  the  meaning  of  a  particular  choice  he  has 
made  in  a  logic  tree  troubleshooting  procedure  (see  Section  8.0) 
or  reminding  the  user  that  the  system  is  in  the  review  mode. 
Feedback  messages  are  also  the  basis  for  structuring  user 
interface  with  the  system  when  the  technician  selects  the  user 
request  mode  of  operation  (see  Subsection  3.6).  In  this  case 
the  feedback  message  becomes  a  special  prompt  for  inputting  the 
user  request  and  disappears  from  the  screen  when  the  request  has 
been  satisfied  oi  canceled.  As  shown  in  Figures  3-17  and  3-18, 
feedback  messages  will  normally  be  displayed  on  the  next  available 
line  of  the  prompt  area. 

Advisory  messages  are  different  from  feedback  messages  only  in 
meaning.  If  a  user  makes  an  error  that  is  recognizable  by 
the  system  (e.g.,  selecting  a  key  code  that  is  not  among  the 
displayed,  available  choices),  requests  information  that  is  not 
in  the  data  base,  or  performs  similar  incorrect  interact  ions ,  an 
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•  REMOVE  FILTER  ASSEMBLY  FROM  FUEL  PUMP: 

1.  POSITION  CONTAINER  BELOW  FILTER  TO  CATCH  DRAINAGE. 

.  MOTE  . 

WIPE  ANY  FUEL  SPILLAGE  FROM  ENGINE  WITH  CLOTH  OR  TOWELS. 


2.  CUT  SAFETY  WIRE  AND  REMOVE  2  BOLTS  «2*  AND  WASHERS. 

3.  WITHDRAW  FILTER  ASSEMBLY  FROM  CAVITY  IN  FUEL  PUMP 

•3*. 


Figure  3-18.  Example  of  inverse  video  coding  of  prompt, 
feedback,  and  advisory  messages  (normal 
dark  on  light  background) . 
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INCORRECT  CODE  INPUT.  [CLEAR]  AND  INPUT  AGAIN. 

DA'!  A  NOT  AVAILABLE.  NEED  HELP?  [LIST  OPTIONS], 

I  FORWARD ]  KEY  NOT  AVAILABLE.  [CLEAR]  Aim  MAKE  A  SELECTION. 


•\  :•/ 1  sory  messages  will  replace  any  standard  prompt  or  feedback 
•  • -^r  av-  that  may  already  be  on  the  last  line  of  the  prompt  area, 
and  wiii  disappear  when  the  user  presses  the  [CLEAR]  key  or 
i  aL.  the  suggested  corrective  action.  Advisory  messages  should 
a  Ath] ignted  to  obtain  maximum  contrast  with  the  prompt  and 
:  •  •dD„ic-.  messages  which  may  also  be  displayed.  If  the  prompt 
.  r  in  inverse  video  and  a  feedback  message  is  present  in  normal 
idee,  the  advisory  message  should  be  in  inverse  video  and 
should  be  a  blinking  message  to  attract  attention.  Figure  3-18 
included  an  example  of  an  advisory  message  along- with  a  standard 
i  rompt  and  a  feedback  message. 


'i .  b  .  1 1  Cal  Louts  Between  Text  and  Illustration 

M  my  *'r ames  of  data  will  include  text  references  to  equipment 
and  components .  When  appropriate  to  the  type  of  data  being 
•>resentod  and  the  needs  of  the  user,  the  referenced  equipment 
and  components  should  be  illustrated  on  the  same  frame.  The 
text  ;or  table)  should  include  a  callout  number,  or  letter  in 
I'Ono  cases,  which  is  keyed  to  the  component  or  equipment  shown 
in  the  illustration.  Callouts  are  preferred  to  the  use  of 
component  names  in  the  illustration.  Names,  which  are  sometimes 
1  t.-ngt.hy ,  require  increased  display  space,  add  clutter  to  the 
. . s: - 1 u y  "i  i  nformation,  and  require  more  visual  search  if  more 
•  nan  or.o  component  is  referenced.  In  text  the  callout  will 
.  ri’i'-.i  i  a  tely  follow  the  narf'  of  the  item.  In  tables  the  callout 
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will  usually  be  in  a  column  which  precedes  the  item  name,  but 
may  be  in  a  column  which  follows  the  name.  The  same  callout 
number  or  letter  will  be  shown  associated  with  the  illustrated 
component  or  equipment. 

In  both  text  (or  tables)  and  illustrations  the  callout  will  be 
symbol-coded  according  to  the  convention  described  in  subpara¬ 
graphs  3. 8. 7. 2  and  3. 8.7.3  to  show  whether  or  not  it  is  selectable 
(see  Figures  3-6  and  3-7) .  In  the  illustration  the  callout 
preferably  will  be  at  the  end  of  a  leader  line,  as  described  in 
subparagraph  3. 8. 7. 8,  or  in  some  cases  placed  directly  on  the 
illustrated  component. 

The  sequence  of  callout  numbering  will  normally  be  the  same 
as  the  order  of  mention  in  the  text,  especially  for  single-frame 
presentations.  For  data  that  is  presented  in  a  seri'  s  of  frames, 
e.g.,  a  Track  3  maintenance  procedure,  the  sequence  of  numbering 
is  determined  by  the  order  of  first  mention  in  the  series  of 
frames  and  maintained  throughout  the  series.  If  the  series  of 
frames  includes  branching  paths,  the  page  sequence  numbering 
convention  described  in  paragraph  3.8.6  is  used  to  determine 
the  order  of  first  mention. 

To  the  extent  feasible  without  violating  these  and  other 
conventions,  placement  of  callouts  in  the  illustration  should 
te  in  lef t-to-right  and  top-to-bottom  order,  or  in  clockwise 
order.  In  the  latter  case,  if  space  permits  and  a  full  surround 
of  callouts  is  used,  the  lowest  number  should  be  at  the  top-left, 
increasing  in  a  clockwise  direction.  In  most  half-frame  illus¬ 
trations,  where  a  full  surround  is  not  available,  clockwise 
numbering  should  begin  in  the  lower-left  corner. 


Although  not  planned  in  the  baseline  system,  other  methods  for 
associating  text  references  to  illustrated  equipment  are 
available  and  should  be  considered.  One  potentially  effective 
‘echnique  is  the  use.  of  highlighting,  either  active  or  passive, 
which  can  reduce  clutter  by  eliminating  callouts  in  the  illus¬ 
tration.  With  active  highlighting,  if  the  technician  needs 
prompt inq  as  to  the  location  of  a  component  referenced  in  the 
text,  he  could  press  a  function  key  (e.g.,  IBLINK])  and  the 
referenced  callout  and  associated  component  in  the  illustration 
would  blink.  In  passive  highlighting,  if  a  line  cursor  is  in 
use  which  causes  each  line  of  text  to  be  highlighted  (as  a 
placeholder) ,  the  associated  components  of  the  illustration  can 
be  highlighted  at  the  same  time.  Each  of  these  methods  has 
sore  advantages  for  skills  improvement  through  OJT,  but  they 
l.'  t.h  have  the  disadvantage  of  requiring  additional  user  inputs 
through  the  control  unit. 

i . 9  COLOR  CODING 


3 .9.1  Introduction  and  Background 

The  use  of  color  in  conjunction  with  presentation  of  information 
has  the  potential  for  greatly  enhancing  the  effectiveness  of  the 
rcsentation,  regardless  of  the  media  by  which  the  information 
r  Resented.  Even  though  the  baseline  presentation  system 
:  ■  ■  s  .i  ",  noted  for  the  automated  delivery  system  program  is  not 
coior-capable ,  the  increasing  availability  and  comparatively 
re  reasonable  costs  for  color  video  systems  make  it  almost 
nwitnble  that  automated  presentation  of  Air  Force  technical 
.  •  t a  will  soon  be  accomplished  "in  color."  The  purpose  of  this 
bsoction  is  to  provide  some  guidance  on  such  use  of  color  so 
‘  a '  tii:/  f  rcsentation  will  improve  performance,  not  merely  be 
;  <  c  hoi  ful .  Unfortunately,  this  elusive  goal  is  made  more 
. . ! icult  since  color  illustrations  cannot  be  used  as  examples 
i  this  report . 


Although  the  use  of  color  in  information  presentation  is  not 
new,  there  is  a  surprising  lack  of  criteria  based  on  research 
in  color  and  its  influence  on  performance.  Military  specifi¬ 
cations  and  standards  contain  requirements  for  color  coding  of 
such  things  as  equipment  types  and  labels,  placards,  etc.,  but 
there  is  practically  no  information  relative  to  the  use  of 
color  in  military  procedures,  and  none  that  specifically  applies 
to  the  presentation  of  such  procedures  via  an  interactive  system. 
In  general,  military  manuals  do  not  use  color  at  all,  the 
exceptions  being  the  use  of  shades  of  blue  in  the  FOMM  manuals, 
and  the  use  of  red  for  highlighting  in  some  of  the  Army's  SPA 
manuals.  Neither  system  requires  the  use  of  color.  A  review 
(Ref.  8)  of  the  literature  for  identification  of  research-based 
color-coding  principles  for  CRT  displays  was  only  partly 
successful,  since  most  of  the  limited  research  was  performed 
using  other  media  (i.e.,  CRT  presentation  was  not  a  consideration) 
Nevertheless,  some  guidance  can  be  provided  based  on  the  findings 
of  the  limited  CRT  color-coding  research  and  by  extension  of  the 
paper-based  findings  until  more  complete  research-based  criteria 
become  available. 

The  findings  of  the  limited  literature  review  (Ref.  8)  provide 
a  basis  for  defining  some  guidelines  for  CRT  color  presentations, 
but  they  should  be  recognized  as  preliminary  pending  performance 
of  directly  applicable  studies.  The  review  and  the  findings 
dealt  with  the  use  of  color  for  coding  purposes;  the  aesthetic 
aspects  of  color  were  not  specifically  treated. 

The  literature  review  identified  three  color-coding  uses  which 
have  strong  support:  (1)  color  coding  can  speed  search  tasks, 

(2)  color  coding  can  speed  count  tasks,  and  (3)  highlighting 
can  be  an  effective  color-coding  technique.  The  use  of  color 
also  has  some  drawbacks:  (1)  increases  in  symbol  size  required 


to  maintain  legibility,  (2)  additional  cost  of  color  monitors, 

(3)  increased  computer  and  software  requirements,  and  (4)  addi¬ 
tional  format  considerations  so  that  color-weak  or  color-blind 
individuals  can  use  the  system. 

One  other  significant  conclusion  is  that  color  seems  to  impart 
qualities  that  other  codes  do  not,  and  researchers  have  not  yet 
determined  what  that  unique  color  quality  is.  The  reason  for 
the  strong  user  preference,  attention-getting,  and  memory 
properties  of  color  are  not  well  understood. 

3.9.2  Color  Selection  and  Coding  Principles 

The  use  of  color  as  a  coding  medium  offers  a  valuable  means  of 
providing  unambiguous,  easily  di scriminable  information  to  the 
viewer.  Among  other  applications ,  color  coding  can  aid  in  the 
perception  of  warning  signals,  the  identification  of  functional 
relationships,  and  the  association  of  displays  with  related 
controls.  When  used  in  a  coding  system,  color  should  always  be 
redundant  with  some  other  cue.  The  information  provided  by  a 
particular  color  should  also  be  indicated  in  some  other  form,- 
e.g.,  location,  orientation,  alpha-numerics,  scale  indications. 
Color  can  be  particularly  useful  as  a  means  for  organizing 
*  .-.formation  and  is  especially  effective  as  a  means  for  coding 
. ow  probability  or  very  important  events. 

The  benefits  of  color  coding  can  be  realized  only  if  color  is 
not  used  indiscriminately.  Excessive  use  may,  in  fact,  provide 
interference  to  effective  performance.  The  same  qualities  which 
make  color  useful  for  coding  can,  if  overused  or  inconsistently 
applied,  result  in  unintended  confusion  and  distraction.  As 
colors  are  used  more  freauently  and  as  the  number  of  different 
colors  used  for  coding  increases,  the  attention-getting  value 


of  each  color  diminishes.  Similarly,  when  a  particular  color 
has  multiple  meanings,  it  both  loses  its  attention-getting 
quality  and  may  lead  to  confusion  or  error. 

All  coding  schemes  must  be  learned.  Learning  of  a  color  code 
can  be  facilitated  by  keeping  the  code  simple  and  by  taking 
advantage  of  common  usage  in  everyday  life.  Complex  or  poorly 
designed  coding  systems  will  detract  from,  rather  than  enhance, 
performance.  The  following  specific  guidelines  should  be 
considered . 

3.9. 2.1  Redundancy .  In  all  applications  of  color  coding,  color 
should  provide  redundant  information.  That  is,  the  pertinent 
information  should  be  available  from  some  other  cue  in  addition 
to  color. 

3.9.2. 2  Number  of  Colors.  The  number  of  colors  used  for  coding 
should  be  kept  to  the  minimum  needed  for  providing  sufficient 
information  and  should  not  exceed  11.  When  used  in  close  associ¬ 
ation,  a  lower  number  is  preferred. 

3. 9. 2. 3  Meaning  of  Colors.  The  meaning,  if  any,  attached  to 

a  particular  color  should  be  narrowly  defined.  When  appropriate 
to  context,  red,  green,  and  amber  (yellow)  should  be  reserved 
for  the  following  uses: 

•  Red :  Unsafe,  danger,  immediate  action  required. 

•  Green:  Safe,  no  action  required. 

•  Amber  (yellow) :  Hazard  (potentially  unsafe) ;  caution, 
attention  required. 

3.9. 2. 4  Consistency  of  Meaning.  The  meaning,  if  any,  assigned 

to  particular  colors  should  be  consistent  across  all  applications. 
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3. 9. 2. 5  Principles  of  Color  Selection.  The  primary  principle 
that  should  be  applied  in  selecting  colors  for  coding  purposes 
which  do  not  have  the  immediate  safety  implications  of  red, 
green,  and  amber  is  to  ensure  that  each  color  is  recognized  as 
different  from  any  other.  Table  3-11  lists  22  colors  of  maximum 
contrast.  Each  successive  color  has  been  selected  so  that  it 
will  contrast  maximally  with  the  color  just  preceding  it  and 
satisfactorily  with  earlier  colors  in  the  list.  The  first 
9  colors  have  been  selected  so  as  to  yield  satisfactory  contrast 
for  red-green-deficient  as  well  as  color-normal  viewers.  The 
remaining  13  colors  are  useful  only  for  color-normal  viewers. 

Table  3-11 

Twenty-Two  Colors  of  Maximum  Contrast 
(Ref.  13) 


Color  Serial  General  ISCC-N8S  ISC^(^BS  Munaell  renotation  of 

or  selection  color  centroid  name  ISCC-NBS  Centroid 

number  name  number  (abbreviation)  Color 


white 

2.5PB  9.5/0.2 

black 

N  0.8 / 

y.Y 

3.3Y  8.0/14.3 

a.P 

6.5P  4  3/9.2 

w.O 

4.1YR  6.5/15  0 

v.I.B 

2.7PB  7.9/6  0 

v.fl 

5  OR  3.9/15  4 

m  y 

4  4Y  7.2/3  8 

mad,  Gy 

3.3GY  5.4/0. 1 

10 

green 

139 

v.G 

3.2G  4.9/11  1 

11 

purplish  pink 

247 

i.pPk 

5.6RP  6. 8/9.0 

12 

blue 

178 

a.B 

2.9PB  4  1/10  4 

13 

yellowish  pink 

26 

i.yPk 

8.4R  7 .0/9. 5 

14 

violet 

207 

t.V 

0.2P  3.7/10.1 

15 

orange  yellow 

66 

v.OY 

B.6YR  7.3/15.2 

16 

purplish  red 

255 

*.pR 

7.3RP  4.4/11  4 

17 

greenish  yellow 

97 

vgY 

9.1Y  8.2/12.0 

18 

reddish  brown 

40 

l.rBr 

0.3YR  3. 1/9.9 

19 

yellow  green 

115 

vYG 

5.4GY  6.8/11.2 

20 

yellowish  brown 

75 

deep  yBr 

8.8YR  3. 1/5.0 

21 

reddish  orange 

34 

v.rO 

9SR  5  4/14  5 

22 

olive  green 

126 

d  OIG 

8.0GY  2.2/3  6 

In  addition,  colors  selected  for  coding  should  contrast  well 
with  the  background  on  which  they  appear.  Ambient  lighting  and 
method  of  generation  of  color  coding  will  influence  the  apparent 
color  of  the  coded  element.  Each  color  selected  for  coding 
should  be  evaluated  on  the  type  of  CRT  on  which  it  will  be 
used,  not  from  hard-copy  or  surface  colors. 

3. 9. 2. 6  Use  of  Color.  The  many  hues  (colors)  and  saturations 
(lightness  and  darkness)  available  in  CRT  displays  are  virtually 
limitless.  Care  must  be  taken  to  select  the  best  colors  and  to 
specify  their  use  such  that  they  will  be  consistent  with  each 
other.  Table  3-12  provides  general  guidelines  for  color 
selection . 


Table  3-12 

General  Characteristics  of  Colors 
Used  in  CRT  Displays  (Ref.  13) 


Bed- Goua  attention-getting  color  Attociated  with  danger. 

W/ow  (ember)- Good  attention  getting  color.  Attociated  with 
caution. 

Green- A  non-attention-getting  color;  eaiy  on  the  tyts.  Aaaociatad 
with  aatiafactory  condition!. 

Black  —  Normally  uaed  at  the  background  color,  i*..  the  color  of 
blank  character  ipaces.  Alto  uted  at  the  action  character  when 
reverie  field  coding  if  employed. 

White  —  A  non-ettent ion-getting  color.  It  thould  be  uaed  for  nendard 
alphanumeric  teat  or  tablet  where  the  information  it  contained  in 
'hr  "hvact*"!  «nrr  nm  *ne  color.  Might  alto  be  uted  for  label!,  coor¬ 
dinate  axel,  dividing  Imei,  demarcation  bracket!,  etc 

Cyan  (light  blue)  — (Same  at  white) -Might  be  uted  in  conjunction 
with  white  to  provide  tome  amount  of  noncrtticei  ditcriminetion 
(e  g.,  ute  cyan  for  tabular  column  heading!  and  demarcation  tmei. 
ute  white  for  alphanumeric  data). 

Blue  (dark)  — Poor  contract  with  dark  background  Not  recom¬ 
mended  for  attention-getting  purpoiei  or  for  information-bearing 
data.  Ute  for  labalt  and  other  edviKjry  type  meueget. 

Magenta  -  A  harth  color  to  the  eye  Should  be  uaed  tparingiy,  end 
for  attention  getting  purpoKi. 

Orange  —  Good  attention-getting  color.  Care  mult  be  taken  that  hue 
it  taiected  to  be  readily  differentiable  from  red.  yellow,  and  wtvte 
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3. 9. 2. 7  Red-Green  Combinations.  Whenever  possible,  red  and 
green  colors  should  not  be  used  in  combination.  Use  of  red 
symbols/characters  on  a  green  background  should  especially  be 
avoided . 

3.9.3  Application  of  Color-Coding  Principles 

This  section  applies  some,  it  not  all,  of  the  color-coding 
principles  and  guidelines  discussed  above  to  the  formats 
developed  for  the  baseline  automated  system.  The  intent  here  is 
nor  to  dictate  which  specific  colors  should  be  used  for  which 
purposes,  but  merely  to  focus  on  some  acceptable  methods  for 
making  effective  use  of  color  for  presentation  of  maintenance 
information  on  CRTs. 

3.9. 3.1  Assumptions.  Development  of  the  guidance  which  follows 
's  based  on  the  following  assumptions: 

a.  The  CRT  screen  will  have  a  dark  (gray)  background  if  back¬ 
ground  color  is  not  introduced. 

b.  The  control  device  may  have  the  capability  for  controlling 
linc-by-linc  "place-holding"  through  cursor  movement,  a 
capability  which  is  not  now  planned. 

c.  Military  specification  requirements  directing  the  use  of 

red  for  warnings,  hazardous  situations,  and  similar  emergency 
type  messages  will  apply. 

3.9. 3.2  Principles  Applied.  The  color-coding  principles  that 
have  been  applied  in  the  guidance  and  examples  which  follow 

i nclude : 

a.  Use  hi gh-contrast  colors  (including  white  on  a  dark  back¬ 
ground)  to  draw  attention  to  the  elements  of  the  instruction. 

b.  Use  relatively  low-contrast  colors  for  relatively  non- 
important  content. 


c.  Use  color  consistently  in  a  series  of  presentations. 

d.  Use  color  to  provide  association  between  related  elements 
of  the  frame  contents. 

e.  Use  as  few  different  colors  as  possible  in  a  single  presen¬ 
tation,  with  seven  as  a  maximum. 

3.9.3. 3  Guidance  and  Examples.  Figure  3-19  illustrates,  at 
much  reduced  scale,  an  example  of  a  troubleshooting  frame  with 
light  characters  on  a  dark  background.  What  this  subparagraph 
will  attempt  to  show,  in  black  and  white,  is  how  up  to  seven 
colors  can  be  used  effectively  for  enhancement  of  the  presen¬ 
tation  and,  it  it  hoped,  of  performance. 

The  colors  which  are  used  are  light  blue  (cyan),  white,  red, 
orange,  yellow,  light  green,  and  purple.  With  the  screen  back¬ 
ground  used,  each  gives  fair  contrast  although  some  are 
obviously  better  in  this  regard  than  others.  Cyan  is  used  as 
the  standard  color  of  non-coded  frame  contents  since  it  has 
relatively  low  contrast  and  little  or  no  attention-getting 
value.  Figure  3-20  illustrates,  by  masking  the  cyan-colored 
contents,  the  data  on  the  frame  which  are  color  coded.  The 
arrows  between  number  callouts  and  illustration  are  in  the  non- 
coded  color  cyan  to  avoid  color-coding  elements  of  the  illustration 
which  have  no  equivalent  element  in  the  text.  In  trials  where 
arrows  carried  the  color  code,  there  was  some  sense  of  it  being 
a  distraction  rather  than  an  aid  to  detection. 

Using  the  same  masking  technique,  Figure  3-21  highlights  the 
use  of  the  color  red  for  the  warning  message  and  the  associated 
step  of  the  procedure.  When  shown  as  white  on  dark,  the  warniiu: 
message  and  the  procedural  step  stand  out  clearly.  However,  the 
color  red  has  relatively  low  contrast  against  a  dark  background. 

To  compensate,  the  warning  message  and  the  associated  procedural 
step  are  color  coded  (red)  in  inverse  video  as  is  highlighted  in 
the  example. 


3  7  4 


or  codinq  principles —  color  coding  principles- 

coding  highlighted.  active  (color- coded ) 

information  highlighted. 
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h  i hi  i  u.  l  i  n  i  associated  text  and  illustration 

i  i  rents  (r.xatnple  2)  . 


Color  can  be  used  equally  effectively  to  associate  key  elements 
of  the  procedural  text  with  the  appropriate  portion  of  an  illus¬ 
tration.  In  the  following  examples,  each  of  the  remaining  colors 
was  used  to  associate  a  term  in  the  text  with  one  of  the 
components  in  the  illustration. 

To  aid  detection,  the  colors  with  highest  background  contrast 
were  used  for  the  smallest  illustrated  components.  The  color 
white  was  used  for  coding  of  the  "bolts,"  as  shown  in  Figure  3-22. 

Assignment  of  the  remaining  colors  is  depicted  in  Figure  3-23. 

Note  that  in  those  instances  where  a  particular  component  is 
named  in  more  than  one  step  the  same  color  code  is  used. 

Similarly,  in  a  series  of  frames  on  the  same  subject  every 
effort  should  be  made  to  use  the  same  color  for  a  particular 
component  that  is  coded  in  each  frame  of  the  series  of  presen¬ 
tations.  This  will  not  always  be  possible  in  procedures  which 
include  many  different  components,  but  every  effort  should  be 
made  to  preclude  the  color  code  for  a  particular  component  from 
changing  in  sequential  frames  of  data  unless  there  is  a  reason 
for  it. 

Even  though  color  coding  is  used,  numbered  callouts  are  still 
used  in  the  text  and  illustration  to  provide  a  means  of  associ¬ 
ation  even  if  the  color  generator (s)  should  fail  or  if  the  user 
is  color  blind  or  color  weak.  To  provided  added  search  redundancy, 
the  numbered  callout  is  color  coded  the  same  as  the  component  with 
which  it  is  associated. 

On  systems  which  have  the  capability  for  toggling  a  cursor  up  and 
down  the  frame  to  "mark"  the  particular  step  in  which  the  user 
is  involved,  the  same  approach  as  already  described  can  be  used 
with  some  modifications.  Cursor  movement  could  be  used  to 


activate  the  color  codes  on  each  line  (and  the  associated 
components  in  the  illustration)  with  all  other  data  in  the 
passive  (cyan)  color.  This  method  can  also  be  used  with  inverse 
color  coding  if  appropriate. 

The  preceding  discussion,  guidance,  and  examples  have  been  based 
on  an  assumed  dark  (gray)  background.  The  same  principles  apply 
if  the  background  is  light,  although  specific  applications  and 
color  selections  may  vary.  In  addition,  and  quite  commonly  on 
color  CRTs,  the  background  itself  may  be  colored,  either  because 
it  is  the  normal  background  for  the  display  or  because  someone 
decides  that  a  colored  background  is  more  impressive  or  attractive. 
Two  cautions  are  in  order: 

a.  Background  color  can  have  significant  influence  on  the 
choice  and  application  of  colors  used  for  coding  purposes. 

Red  and  green,  for  example,  should  not  be  superimposed  since 
this  sometimes  results  in  perceived  color  reversals. 

b.  Background  colors  should  not  be  changed  indiscriminately,  as 
is  often  done  in  briefing  types  of  presentations.  If  back¬ 
ground  color  changes,  it  should  signify  an  important  difference 
in  the  nature  of  the  information  being  displayed  (e.g.,  pro¬ 
cedural  data  versus  pool  data;  or  maintenance  procedures 
versus  troubleshooting  procedures) . 

J.H)  PRINT  CAPABILITIES 

The  baseline  system  has  very  limited  provisions  for  allowing  the 
user  to  obtain  paper  copy  of  data  displayed  by  the  system.  In 
♦'act,  it  was  an  initial  system  requirement  that  the  automated 
delivery  system  obviate  the  need  for  any  paper-based  TO  or 
related  materials.  Although  this  requirement  was  deleted  during 
i he  course  of  the  project,  the  system  concept  (including  format 


characteristics)  has  continued  to  place  little  dependence  on  the 
availability  of  supporting  printed  material,  or  on  the  capability 
for  obtaining  a  display  printout. 

It  was  recognized,  however,  that  some  information  in  the  data 
base  will  have  increased  value  to  a  technician  if  it  is 
transportable,  that  is,  if  it  can  be  used  when  the  technician 
is  out  of  view  of  the  display  device.  For  example,  input 
conditions  frames  will  list  equipment,  materials,  and  supplies 
that  may  be  needed  for  performing  a  maintenance  task.  If  the 
technician  must  go  elsewhere  to  obtain  such  items,  having  a 
printout  of  the  list  will  remove  the  need  to  make  a  handwritten 
copy  or  rely  on  memory. 

Whether,  and  how  extensive,  a  print  capability  should  be 
provided  is  a  decision  that  should  be  based  on  the  anticipated 
needs  of  the  user.  In  general,  printout  capabilities  should  be 
strictly  limited.  Otherwise,  because  of  resistance  to  change 
factors,  some  technicians  may  p  int  everything  in  order  to  have 
their  own  paper-based  TO.  In  addition  to  defeating  the  purpose 
of  the  system,  this  would  remove  TO  data  from  AFTO  system 
controls.  It  would  also  increase  the  likelihood  of  erroneous  or 
obsolete  procedures  being  followed  since  corrections  and  changes 
would  not  be  incorporated  automatically. 

If  only  certain  data  are  to  be  made  available  in  printout  form, 
such  data  should  not  be  on  the  same  frame  with  data  which  should 
not  be  printed,  and  the  prompt  should  provide  appropriate 
instructions;  e.g., 

FOR  PRINT  OF  THIS  LIST:  INPUT  KEY  CODE  [A] ;  [ENTER] . 

For  more  complete  illustrations,  see  the  input  conditions  examples 
in  Sections  7.0  and  8.0. 
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If  certain  task  sequences  are  to  be  made  available  in  printout 
form,  instructions  for  obtaining  print  copy  should  be  included 
in  the  input  conditions  frame  for  the  task.  This  might  be 
appropriate  m  cases  where  equipment  cannot  be  introduced  to  the 
site  where  maintenance  is  to  be  performed. 

If  printouts  are  to  be  generally  unconstrained,  the  control  unit 
keyboard  should  have  a  [PRINT]  function  key. 


SECTION  4.0 


DATA  BASE  ACCESS,  FRONT  MATTER, 
AND  COMMON  FORMATS 


4 . ]  SCOPE 

This  section  discusses  the  logic  inherent  in  the  system  to  aid 
users  to  gain  initial  access  to  particular  data,  the  introductory 
fiamrs  which  are  accessed  in  the  standard  mode  of  operation,  and 
the  formats  which  are  relatively  common  in  all  parts  of  the  data 

base . 

4 . 2  ACCESS  PATHS 

/.s  with  any  TO,  the  user  must  first  locate  the  correct  "manual" 
before  the  data  inside  are  of  any  use.  Access  to  the  data  base 
is  based  on  a  specified  logic  which  first  ensures  that  the 
technician  understands  the  automated  delivery  system  and  that 
he/she  has  been  authorized  to  perform  maintenance  using  the 
system,  or  otherwise  has  need  to  enter  the  data  base.  The 
standard  access  path  then  follows  a  process  of  assisting  the  user 
in  defining  needs,  progressively  narrowing  the  choices  until  the 
iesired  information  is  obtained.  After  gaining  initial  system 
access,  experienced  users  can,  if  desired,  bypass  any  portion  of 
this  "front  matter"  by  going  directly  to  the  data  they  want  in 
the  user  request  mode.  The  essential  steps  in  the  access  path 
are  depicted  in  Figure  4-1. 

4.2.1  Start-Up 

There  are  two  phases  involved  in  system  activation.  The  first 
step,  not  shown  in  Figure  4-1,  is  to  power-up  the  system  as  a 
whole.  This  step  will  normally  be  accomplished  by  the  shift  * 
supervisor,  senior  NCO,  or  other  responsible  authority,  and  is 
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performed  at  the  computer.  It  does  not  involve  use  of  the  con¬ 
trol  unit  except  as  may  be  appropriate  for  testing.  The  second 
phar  •  is  to  activate  the  control/display  interface.  This  is 
i,  .  omnl  isliod  by  pressing  the  [START]  key  on  the  control  unit. 

(If  the  interactive  system  in  use  is  a  portable,  self-contained 
system,  both  activation  steps  are  included  in  the  START  function.) 
The  initial  presentation  on  the  display,  an  example  of  which  is 
shown  in  Figure  4-2,  identifies  the  system,  a  necessary  step  for 
first- time  users,  and  provides  guidance  for  entering  the  data 
base.  (The  name  "VAMIS"  which  is  shown  in  Figure  4-2  is  for 
illustrative  purposes  only;  i.e.,  that  a  name  should  be  given 
to  the  system  with  which  users  can  identify.)  The  brief  expla¬ 
nation  provided  on  this  frame,  dealing  with  the  experimental 
nature  of  the  system,  will  change  when  the  automated  system 
achieves  operational  status. 

The  initial  frame  provides  instructions,  in  the  expanded  prompt 
area,  for  both  authorized  users  and  other  personnel.  Users  who 
follow  the  first  prompt  are  "signing  on"  the  system,  as  discussed 
in  paragraph  4.2.2.  The  prompt  for  other  personnel  is  somewhat 
more  detailed  since  such  personnel  may  be  totally  unfamiliar  with 
the  system.  Compliance  with  the  prompt,  pressing  [FORWARD] , 
takes  the  user  to  the  non- TO  portion  of  the  data  base  where  an 
explanation  of  the  system  and  user  guidance  is  provided.  This 
aspect  of  the  system  is  described  in  more  detail  in  Section  9.0. 

4.2.2  Signing  On 

Users  who  follow  the  first  prompt  on  the  system  title  frame 
(Figure  4-2)  will  use  the  Input  portion  of  the  control  unit 
to  enter  their  assigned  authorization,  or  access,  code.  For  a 
particular  system  the  authorization  code  can  be  a  simple  password 
or  a  complex  string  of  alphanumeric  characters  known  only  to  the 
individual  user,  the  responsible  authority  for  the  facility,  and 


the  computer.  The  baseline  approach  used  here  is  to  use  the 
individual's  service  number/social  security  number  (SSN)  as  the 
content  of  the  authorization  code.  The  response  of  the  prompt 
to  the  user's  input  then  would  be: 

O  AUTHORIZED  USERS:  INPUT  AUTHORIZATION  CODE 

W  [###  ##  ####];  [ENTER]. 

The  computer  compares  the  entered  code  with  the  list  of  codes 
for  authorized  users  and,  if  acceptable,  logs  the  individual  onto 
the  system.  If  the  code  is  not  valid,  an  appropriate  advisory 
message  is  displayed  and  the  individual  is  denied  access  to  the 
data  base. 


*  VAMIS 


6AA  9900 1 B 


VERSATILE:  ALTO 'EAT  ED  “AINTENANCt  INFORMATION  SYSTEM 


THIS  IS  AN  EXPERIMENTAL  SYSTEM  FOR  PRESENTING  CERTAIN  TYPES 
OF  MAINTENANCE  PROCEDURES  AND  RELATED  INFORMATION.  SOME 
PERSONNEL  HAVE  BEEN  AUTHORIZED  TO  USE  THE  SYSTEM  FOR  THE 
CONDUCT  OF  MAINTENANCE  INSTEAD  OF  USING  THE  OFFICIAL  AIR 
FORCE  TECHNICAL  ORDER.  THESE  PERSONNEL  HAVE  BEEN  ISSUED  A 
USER  ACCESS  CODE  AND  HAVE  BEEN  INSTRUCTED  IN  THE  OPERATION 
#  OF  THIS  COMPUTER-BASED  TECHNICAL  ORDER. 


QAUTHORIZED  USERS:  INPUT  AUTHORIZATION  CODE  [  ];  [ENTER]. 

DALL  OTHER  INTERESTED  PERSONNEL:  PRESS  THE  KEY  ON  THE 
*  CONTROL  UNIT  LABELLED  "FORWARD". 


Figure  4-2.  Example  of  VAMIS  title  frame  and  access 
instructions . 


The-  SKimnq-on  process  also  accomplishes  several  other  actions 
handled  by  the  computer  based  on  its  programming.  If  any  limi¬ 
tations  on  data  base  access  have  been  placed  on  the  particular 
user,  e . g . ,  only  authorized  to  perform  maintenance  on  certain 
systems,  or  not  allowed  access  to  specified  levels  of  classified 
j  i. at  ion ,  the  computer  will  scale  the  available  data  base 
accordingly.  The  computer  is  instructed  to  provide  the  data 
at  the  level  of  detail  specified  for  the  individual  user  by  a 
supervisor,  or  according  to  some  other  criterion  such  as  AFSC/ 
skill  level.  Users  who  automatically  are  presented  technical 
information  at  less  than  the  most  detailed  level  (Track  3)  will 
be  able  to  obtain  a  more  detailed  presentation  through  use  of  the 
options  list  (see  Figure  4-9).  They  will  not,  however,  be  able 
U>  obtain  less  detailed  presentations  than  they  are  authorized 
int  if  the  computer  has  been  so  instructed  by  the  responsible 
individual.  This  will  normally  occur  when  the  user  has  demon¬ 
strated  sufficient  proficiency  in  performance  at  the  assigned 
Level  of  detail.  It  may  also  be  appropriate  to  authorize 
di  if  (/rent  levels  of  detail  for  different  TOs,  and  to  authorize 
temporary  presentations  at  less  detailed  levels  for  purposes  of 
supervised  OJT. 

Nete  tint  once  a  user  has  signed  on,  the  system  will  assume 
’  lv!‘  t.he  same  individual  is  the  user  until  he/she  signs  off 
i  ..  pressing  [STOP]  on  the  control  unit)  .  In  order  to  prevent 
*  hor i  zed  use  of  an  unattended  system  that  was  left  running, 
i  well  as  inappropriate  use  by  an  authorized  user,  it  is 
;  ■  ■■  Ycimended  that  several  other  security  provisions  be  programmed 
;>.;o  :  be  system: 

•  .-lock  that  will  shut  down  the  system  automatically  if  no 


cent  rol  inputs  have  been  made  during  a  specified  period  of 
:  i  r>u • ,  c  .  .  ,  JO  minutes. 


•  A  system-generated  request  to  confirm  the  user’s  author¬ 
ization  code  if  data  not  directly  related  to  that  which 
has  been  in  use  are  requested,  in  either  the  standard  mode 
or  user  request  mode  of  operation.  Decision  criteria  such 
as  the  user's  AFSC  can  be  applied  for  this  purpose. 

4.2.3  Entering  the  Data  Base 

When  an  authorized  user  has  correctly  entered  his/her  code, 
and  the  system  accepts  it,  the  user  is  presented  with  the 
initial  frame  of  information  to  assist  entering  the  data  base. 
As  mentioned  above,  and  illustrated  in  Figure  4-1,  the  user 
can  access  the  information  in  either  the  standard  mode  or,  if 
sufficiently  knowledgeable  of  both  the  system  and  the  data 
needed,  in  the  user  request  mode  of  operation.  Obtaining  data 
in  the  user  request  mode,  regardless  of  where  the  user  is  in 
the  data  base,  is  described  in  paragraph  3.6.4.  Initial  data 
base  access  in  the  user  request  mode  is  also  discussed  in 
Subsection  4.4. 

4.3  STANDARD  MODE  ACCESS 

Access  to  contents  in  the  standard  mode  is  based  on  selection 
from  a  series  of  menu-like  tables  of  contents  and  specialized 
selection  frames  that  progressively  narrow  the  choices  until 
the  technician  reaches  the  particular  data  needed.  As  in  paper 
based  TOs ,  some  required  "front  matter"  frames  are  included  in 
the  sequence  to  ensure  that  the  user  is  made  aware  of  important 
information.  With  such  frames  the  user  acknowledges  the  pre¬ 
sentation  of  the  information  by  use  of  the  [FORWARD]  key  (rathe 
than  by  menu  selection)  to  obtain  the  next  frame.  Since  these 
menus  and  other  front  matter  frames  contain  no  procedural  data 
for  performing  maintenance,  they  are,  technically,  pool  data. 
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However,  since  they  are  necessary  for  gaining  access  to  proce¬ 
dural  data  as  well  as  pool  data,  they  are  formatted  in  accordance 
with  the  viewing  distance  criteria  of  procedural  data. 

4.  i.l  TO  Selection  Frame (s) 

Assuming  that  the  system  contains  more  than  one  TO  in  the  data 
base,  the  first  task  of  the  technician  is  to  select  the  parti¬ 
cular  TO  needed.  If  the  system  is  dedicated  to  a  single  TO, 
this  frame  is  not  needed.  Conversely,  if  the  system  is  part  of  a 
large,  central  shop  system,  there  may  be  many  individual  TOs  in 
the  data  base,  requiring  multiple  frames  for  making  the  selection. 
(TL  is  in  these  instance:-;  where  the  user  request  mode  of  access, 
shown  in  the  access  rath  of  Figure  4-1,  may  be  quicker  than 
menu  selection.)  Figure  4-;  illustrates  an  example  of  a  typical 
TO  selection  menu,  c  .m;  :•  t-.  *n  one  frame.  Listed  TOs  should  be 
m  numerical  sejucia.-  by  T  number.  If  listings  will  be  lengthy, 
e.g.,  for  central  systems,  the  user  should  have  the  alternative 
of  selecting  from  a  topical  menu  or  index  which  presents  the  TOs 
alphabetically  by  equipment  name,  etc.  Whichever  method  is  used, 
selection  of  the  key  code  associated  with  a  listed  TO  obtains 
the  title  frame  for  that  TO. 


4.4.2  TO  Title  Frame 

Th"  TO  title  frame,  an  example  of  which  is  shown  in  Figure  4-4, 
has  the  same  purpose  and  use  as  in  paper-based  manuals.  It 
provides  full  identification  of  the  TO  which  follows,  including 
the  currency  of  the  contents,  allowing  the  user  to  confirm  that 
this  is  the  TO  wanted.  Assuming  that  it  is,  the  user  presses 
[FORWARD]  to  obtain  the  next  frame,  the  nature  of  which  depends 
or  'he  TO  content.  If  it  is  not  the  desired  TO,  the  user  can 
: >  turn  to  the  (first)  selection  menu  frame  by  pressing  [REPEAT 
F DKNCE]  ,  or  by  pressing  [LIST  OPTIONS]  and  selecting  the  TO 
v-  iection  frame  from  the  options  list. 


,v 


KEY 

[  ] 

A 


T.O.  NUMBER 
11B29-3-2S-2-AA 


1 2R2-2ARC1 64-2-AA 


TITLE 

AIRCRAFT  BOMB  EJECTOR  RACK  ASSEMBLY 
MAU-12  FIELD  MAINTENANCE  AND 
ILLUSTRATED  PARTS  BREAKDOWN. 

RADIO  SET  AN/ ARC- 1 64 ( V )  INTERMEDIATE 
MAINTENANCE  INSTRUCTIONS  WITH 
ILLUSTRATED  PARTS  BREAKDOWN. 


*  OF0R  T-°-  NEEDED:  INPUT  KEY  CODE  [  ];  [ENTER], 


V 


T 


J- 


Figure  4-3- 


Example  of  list  of  Technical  Orders  in  the 
VAMIS  data  base. 


4.3.3  Other  Front  Matter 

The  next  type  of  material  to  be  presented  in  the  accessing 
process  depends  primarily  on  TO  content,  as  is  illustrated  in 
Figure  4-1.  Possibilities  discussed  here,  in  the  order  of  their 
presentation  if  used,  are  the  model/series  ("mini-TO")  selection 
menu,  warning  frames,  and  general  table  of  contents.  Examples 
of  some  other  formats  that  are  typically  included  as  front 
matter  in  paper  TOs  are  presented  in  Section  5.0. 


4.  3.  3.1  Model. /Series  Selection  Menu.  This  format,  an  example 
of  which  is  depicted  in  Figure  4-5,  represents  one  of  the  more 
significant  contributions  which  can  be  made  by  an  automated 
delivery  system.  One  of  the  serious  problems  that  occurs  in 
paper-based  TOs  is  that  after  a  hardware  system  has  been  fielded, 
the  modification  and  improvement  cycle  generally  begins.  The 
result  is  that  after  a  few  years  more  than  one  version  of  the 
system  exists,  each  of  which  must  be  accurately  reflected  in 
the  TO.  If  the  differences  are  extensive,  separate  TOs  may  be 


prepared  for  each  model  or  series.  Less  extensive  differences 
are  likely  to  be  reflected  in  a  single  TO  with  separate 
descriptions,  procedures,  and/or  illustrations  provided  where 
differences  exist  for  each  of  the  models  or  series  of  equipment 


TO  1 1 B  2  9 -  3-25-2-AA  94-10-00 

MAU-12  MODEL/SERIES  SELECTION  MENU 


6GD  000058 


*  THIS  T.O.  HAS  INFORMATION  FOR  MORE  THAN  ONE  TYPE  OF  MAU-1? 
EQUIPMENT.  SELECTION  OF  THE  TYPE  OF  SPECIFIC  INTEREST  IS 
NECESSARY  AND  HILL  SIMPLIFY  YOUR  TASK. 


USAF  TYPE 

MAU-12A/A 
MAU-12B/A 
MAU-12C/A 
MAU-I 2C/A 
MAU-I2C/A 


PART  NUMBER 

63J14360 
64J132I0 
6  9 J 1 3060-1 
6  9  J 1  3060-3 
69J1  3060-5 


1095-00-017-8902 

1095-00-758-8774 

1095-00-401-2664 

1095-00-025-5657 

1095-00-166-4286 


D  INPUT  APPROPRIATE  KEY  CODE:  [  ];  [ENTER], 


Figure  4-5.  Example  of  VAMIS  model/series  selection 
menu  frame. 


The  philosophy  is  to  provide  a  front-end  method  of  selecting 
the  particular  model  or  series  of  equipment  which  is  of  interest 
and  letting  the  computer  assemble  a  "mini-TO"  which  contains  the 
applicable  information.  Some  data  in  the  mini-TO  will  be  common 


V  V 
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to  all  models/series,  some  will  be  common  to  several  but  not 
all,  and  some  will  be  specific  to  a  particular  model.  In  some 
instances  it  may  be  more  appropriate  for  the  model/series 
selection  menu  to  come  after  the  general  TOC  in  the  access  path; 
e.u.,  when  differences  are  at  a  level  low  enough  that  neither 
the  warning  frames  nor  TOC  is  affected. 

L'so  of  this  approach  has  both  significant  advantages  and  impor¬ 
tant  costs.  Duriny  data  preparation  it  will  be  necessary  for  the 
preparing  activity  to  designate  the  model/series  applicability 
of  all  of  the  daua  which  is  prepared,  whether  unique  to  a  series 
or  common  to  more  than  one  series,  and  the  applicability  to  each 
new  frame,  or  revised  frame,  of  data.  Computer  programming  must 
bo  such  that  every  applicable  frame  is  assembled  in  the  correct 
sequence,  with  no  omissions  and  no  inappropriate  inclusions. 

The  advantages  are  bo- h  to  the  user  and  to  the  data  preparers, 
or. co  a  mini-TO  is  assembled,  there  will  be  many  fewer  requirements 
for  making  a  selection  of  the  applicable  model/series  during  the 
performance  of  a  maintenance  action,  although  this  will  still 
occur  for  parts  differences  below  the  model/series  level. 

4 . 3 . 3 . 2  Warning (s)  Frames.  These  frames  contain  the  general 
warning  that  applies  to  the  system  as  a  whole,  or  to  the  model/ 
series  selected.  Requirements  for  such  warnings  and  the  content 
to  be  included  an;  the  same  as  for  paper-based  TOs .  Construction 
of  the  warnings  (and  cautions,  if  applicable)  should  follow  the 
same  guidelines  specified  for  in-text  warnings  and  caution 
messages  in  paragraph  3.8.8. 

4. 3.  3. 3  Table  of  Contents  (TOC) .  The  standard  mode  of  access 
and  use  depends  heavily  on  the  selection  of  the  specific  data  of 
interest  from  table  of  contents  menus.  Figure  4-6  provides  an 
example  of  a  general  table  of  contents  frame  from  which  the  user 
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will  select  the  type  of  data  he/she  wants  to  access  from  the 
overall  TO  (or  mini-TO) .  Figure  4-7  illustrates  an  example  of  a 
more  specific  table  of  contents,  covering  one  particular  part  of 
the  data  base.  Selection  from  a  TOC  at  this  level  of  specificity 
will  normally  yield  the  initial  frame  of  the  data  wanted  by  the 
user. 


r- 


TO  17B29-3-25-2-AA  94-70- 

MAU- 1 2 A/ A  GENERAL  TABLE  OF  CONTENTS 


6GD  00006B 


KEY 

[  ] 
A 
B 
C 
0 
E 


TITLE 

INTRODUCTION 

DESCRIPTION  AND  LEADING  PARTICULARS 
PREPARATION  FOR  MAINTENANCE 
THEORY  OF  OPERATION 
FIELD  MAINTENANCE  INSTRUCTIONS 


F  OVERHAUL  INSTRUCTIONS 
G  DIFFERENCE  DATA  SHEETS 
h  ILLUSTRATED  PARTS  BREAKDOWN 

I  FUNCTION  DIAGRAMS 


INPUT  APPROPRIATE  KEY  CODE  : 


];  [ENTER]. 


Fioure  4-6. 


Example  of  VAMIS  nencral  taolc  of  contents 
(TOC)  frame. 


»  TO  1C-141A-2-AA  73-00-00  6 JG  07896D 

C-141A  POWER  PLANT:  4.  ENGINE  FUEL  SYSTEM  MAINTENANCE 
TABLE  OP  CONTENTS 

TASK  DESCRIPTION 

[  ] 

1  FUEL  SHUTOFF  DURING  MAINTENANCE. 

2  FUEL  PUMP  -  REMOVE  &  INSTALL. 

3  FUEL  PUMP  FILTER  ELEMENT  -  REMOVE  &  INSTALL. 

4  FUEL  CONTROL  UNIT  -  REMOVE  t  INSTALL. 

5  FUEL  CONTROL  FILTER  ELEMENT  -  REMOVE  A  INSTALL. 

6  FUEL  DEICER  FILTER  AIR  VALVE  &  ACTUATOR  -  REMOVE  l  INST. 

7  FUEL  PUMP  DIFFERENTIAL  PRESSURE  SWITCH  -  REMOVE  &  INST. 

8  FUEL  FLOW  TRANSMITTER  -  REMOVE  t  INSTALL. 

9  FUEL  INLET  PRESSURE  SWITCH  -  REMOVE  &  INSTALL. 

10  FUEL  DEICER  FILTER  ELEMENT  -  REMOVE  t  INSTALL. 

11  FUEL  SHUTOFF  ACTUATOR  -  REMOVE  &  INSTALL. 


.  • *  * »  m. 


0  FOR  DATA  NEEDED:  INPUT  TASK  NUMBER[  ]  -.[ENTER] . 


Fiaure  4-7.  Example  of  VAMIS  procedures  table  of  contents 
(TOC)  frame. 

The  number  of  frames  in  between  the  general  TOC  and  the  specific 
TOC  represented  by  these  two  examples  depends  primarily  on  the 
overall  size  of  the  TO  and  the  type  of  information  sought  by  the 
user.  There  may  be  several  sectional  title  frames  for  specific 
parts  of  the  data  base,  such  as  the  Illustrated  Parts  Breakdown 
{ I  PR )  and  some  intermediate-level  TOCs.  Each  title  frame  and  TOC 
should  be  prepared  to  the  viewing  distance  criteria  for  the  data 
encompassed  by  it. 
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Construction  of  TOCs  for  greatest  user  efficiency  is  discussed  in 
paragraph  4.5.1. 

4.4  USER  REQUEST  MODE  ACCESS 

As  was  depicted  in  Figure  4-1,  once  the  user  has  signed  on  the 
system,  any  part  of  the  data  base  to  which  the  user  is  author¬ 
ized  access  can  be  entered  in  the  user  request  mode.  For  the 
knowledgeable  technician  this  can  be  a  much  more  efficient  path 
than  entering  via  the  standard  mode.  It  is  not  necessary  that 
the  technician  know  the  exact  frame  of  data  needed  and  what  code 
combination  is  necessary  to  obtain  it.  Just  knowing  certain 
identifiers  and  how  to  interact  with  the  system  in  the  user 
request  mode  can  produce  significant  shortcuts. 

Figure  4-8  illustrates  one  way  that  a  technician  might  access 
information  in  the  user  request  mode,  starting  with  the  initial 
sign-on  to  the  system.  Definitions  of  the  input/output  quali¬ 
fiers  were  presented  in  Table  3-7.  Combinations  of  acceptable 
qualifiers  and  content  identifiers  were  presented  in  Table  3-5. 

The  rule  of  thumb  for  the  user  request  mode  is  that  the  system 
will  provide  the  data  requested  (assuming  they  are  available) 
even  if  they  are  not  what  the  user  expected  or  wanted.  Thus,  the 
burden  is  on  the  user  to  know  what  to  request  and  how  to  request 
it.  A  second  condition  of  user  request  mode  interaction  is  that 
pressing  [USER  REQUEST]  is  necessary  before  each  request  since 
the  system  reverts  to  the  standard  mode  as  soon  as  the  frame  of 
data  resulting  from  the  request  is  displayed.  One  exception  to 
both  of  these  norms  is  apparent  in  Figure  4-8:  If  the  data 
requested  by  the  user  must  first  be  identified  according  to 
model/series,  the  applicable  model/series  selection  menu  (see 
Figure  4-5)  is  inserted  in  the  sequence  by  the  system.  When 


SYSTEM  "ON- 


MODE 


PROMPTS  (NOTE  2) 


I 


l START) 


VAMIS 

TITLE 

FRAME 


* 


[  ###  ##  ####  ] 
[ENTER! 


[TO  11629  3  25  2  AA] 
IENTER] 


[MC  94  10-00  FI] 
(ENTER) 


r  > 

MODEL/SERIE! 
SELECTION 
iMfcNU 


3 


(NOTE  II 


( A 1  [ENTER] 


A 


•  FAULT  ISOL 
|  ICP  FOR 
l  EQUIPMENT 


SM  AUTHORIZED  USERS: 

INPUT  AUTHORIZATION  CODE  I  I.  [ENTER] 


SM  INPUT  KEY  CODE  FOR  TO.  NEEDED:  |  ).  [ENTER] 


URM  INPUT  USER  REQUEST:  [  );  [ENTER], 


SM  FOR  NEXT  FRAME:  [FORWARD] 


URM  INPUT  USER  REQUEST:  [  );  [ENTER] 


URM  INPUT  APPROPRIATE  KEY  CODE  [  1:  [ENTER], 


SM 


1 


o 


legend 


OPTION 

FUNCTION  KEYS 
ALPHANUMERIC  (SELECTION) 
ALPHA-NUMERIC  (USER  REOUEST  MODE  I 
TO  FIRST  FRAME  IF  PART  OF  SEQUENCE 
TO  SPECIFIC  FRAME  WITHIN  SEQUENCE 


NOTES 

1  THIS  FRAME  IS  INSERTED  IN  SEQUENCE  ONLY  IF  A  MODEL/SERIES  SELECTION  MUST  BE  MADE 
IN  ORDER  TO  PROVIDE  THE  CORRECT  PROCEDURE. 

2  THE  SM  OR  URM  PROMPT  ON  THE  ASSOCIATED  FRAME  OF  DATA. 


Figure  4-8.  Representative  data  access  path  in  user  request  mode 


the  technician  makes  a  selection  from  the  menu,  the  inteirupted 
user  request  is  then  completed  without  re-input  of  the  request. 

4.5  COMMON  FORMATS 

Formats  in  the  automated  delivery  system  have  many  common  char¬ 
acteristics.  At  the  sub- format  level,  the  codes  and  conventions 
discussed  in  Subsection  3.8  are  used  in  all  types  of  data.  In 
procedural  data,  i.e.,  maintenance  procedures  and  troubleshooting 
procedures,  the  logic  (and  to  some  extent  the  format)  is  the  same 
for  all  three  tracks,  differing  mostly  in  level  of  detail.  Menus 
are  used  throughout  the  data  base.  The  purpose  of  the  menu  is  to 
permit  the  user  to  quickly  and  efficiently  make  a  choice  of  types 
of  information  available.  The  two  primary  examples  of  menus  are 
the  table  of  contents,  discussed  above,  and  the  options  list. 

4.5.1  Menus 

Most  menus  will  consist  of  two  columns  of  information:  listing 
of  information  within  some  category,  and  listing  of  associated 
codes,  selection  of  which  will  access  the  information.  In  menus 
of  this  type,  the  selection  codes  should  be  in  a  column  at  the 
left  margin  of  the  frame.  The  listing  of  available  information 
should  be  in  a  column  to  the  right  of  the  selection  codes,  with 
not  more  than  five  character  spaces  separation.  If  no  natural 
hierarchy  exists  in  the  information  listing,  a  line  should  be 
skipped  at  intervals  in  order  to  provide  visual  groupings  of 
information.  The  maximum  for  interval  spacing  should  be  after 
every  ten  lines,  with  a  preferred  interval  after  every  five 
lines.  Selection  codes  should,  if  practical,  consist  of  not 
more  than  two  characters.  When  possible,  the  normal  means  of 
identification,  e.g.,  task  number,  should  comprise  the  selection 
code.  When  the  information  included  in  the  menu  has  a  ’’normal” 
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order  or  sequence,  it  should  be  listed  in  that  order.  If  there 
is  no  "normal"  order,  the  information  should  be  presented  in 
some  logical  sequence  or  groups,-  e.g.,  by  types  of  information. 
Where  it  can  be  determined,  the  sequence  of  presentation  should 
be  based  on  the  likelihood  of  the  information  being  needed  by 
the  user,  if  it  does  not  disrupt  a  normal  or  logical  sequence. 

The  simple  menu  can  be  presented  in  multiple  columns  if  space 
permits  and  the  type  of  data  lends  itself  to  this  kind  of 
presentation.  Examples  of  multiple-column  menus  are  included 
in  the  ;  ool  data  examples  in  Sections  5.0  and  6.0.  When  multiple 
column  menus  are  used,  a  vertical  line  should  separate  the  major 
col umns . 

In  some  cases  it  is  appropriate  to  have  more  than  one  choice  for 
a  particular  topical  listing.  For  example,  in  the  IPB  the  user 
can  choose  either  a  breakdown  illustration  or  maintenance  parts 
list  from  a  single  listing  of  major  assemblies  (see  Figure  6-12 
in  Section  6.0).  The  selection  code  columns  should  be  side-by- 
side  at  the  left  of  the  frame.  The  codes  used  should  be 
distinctly  different  in  each  column,-  e.g.,  all  numbers  in  the 
first  column  and  all  alphabetic  characters  in  the  second  column. 

4.5.2  Options  List. 

The  options  list  is  a  special  purpose  menu  which  is  specifically 
oriented  to  the  philosophy  of  data  availability  and  presentation, 
while  it  is  part  of  the  standard  mode  of  operation,  it  represents 
a  compromise  between  the  TOC  accessing  methods  of  the  standard 
mode  and  the  tree  accessing  methods  of  the  user  request  mode. 

The  concept  of  the  options  list  is  that  for  every  frame  of  data 
in  the  data  base  there  are  a  relatively  predictable,  limited 
number  of  logical  choices  of  related  information  which  the  user 
might  need  or  want.  Some  of  these  choices  will  be  specifically 


associated  with  the  "reference"  frame;  others  will  be  predictable 
choices  even  if  they  contain  no  technical  information  related  to 
the  reference  frame.  Figure  4-9  illustrates  a  typical  options 
list  such  as  might  be  associated  with  a  frame  of  troubleshooting 
procedures. 
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Figure  4-9.  Example  of  VAMIS  options  list  frame. 


The  reference  frame  for  the  options  list  in  this  example  is  a 
Track  2  logic  tree  frame  for  fault  isolation  (see  Figure  8-5  in 
Section  8.0) .  The  options  list  would  be  accessed  by  the  user 
by  pressing  [LIST  OPTIONS]  on  the  control  unit.  The  reasons  for 
wanting  the  options  list  could  vary  from  simple  curiosity,  to 
need i n .j  specific  supplementary  information,  to  needing  help. 

The  options  list  should  always  include  the  option  for  change 
in  level  of  detail  (either  more  or  less,  if  available). 

Track  2  and  3  options  list  should  always  show  less  detail  as  an 
option ;  Track  1  and  2  options  list  should  always  show  more  detail 
as  an  option.  If  a  user  who  is  not  authorized  to  use  a  less 
detailed  track  selects  that  option,  an  advisory  message  should  be 
displayed  which  states  why  less  detailed  data  are  not  available. 
This  approach  will  still  provide  a  means  by  which  the  more 
_::per  ionced  tecnician  who  has  selected  more  detailed  data  can 
get  back  to  the  original,  less  detailed  track.  It  should  not 
include  choices  that  the  user  could  have  made,  either  directly 
or  indirectly,  while  viewing  the  reference  frame.  For  example, 
troubleshooting  with  the  logic  tree  requires  the  user  to  answer 
yes  or  no  to  a  series  of  questions  regarding  the  conditions 
found.  Inputting  those  answers  accesses  other  parts  of  the 
.imiJc  tree  or  other  logic  trees  or  maintenance  procedures 
whi on  would  be  needed  to  continue.  If  the  same  data  were  made 
available  via  an  options  list,  the  user  could  bypass  answering 
:h<-  logic  tree  questions,  casting  doubt  on  the  thoroughness  of 
t-li"  laa  It  isolation  activity.  If  none  of  the  options  listed 
e.  of  interest  to  the  user,  the  reference  frame  (from  which 
tic  user  accessed  the  options  list)  can  be  obtained  by  pressing 
i  M'Tl’HN ]  on  the  control  unit. 


SECTION  5.0 
POOL  REFERENCE  DATA 


5.1  INTRODUCTION 

Reference  data  in  pool  include  all  TO  information  which  is  not 
specifically  designated  as  procedural  ("track")  data,  procedural 
support  pool  data,  or  front  matter.  This  category  encompasses 
information  about  the  TO  itself  and  information  which  may  be 
helpful  to  a  technician  in  understanding  the  system  on  which 
maintenance  is  to  be  performed.  Reference  data  are  always 
prepared  at  the  Level  3  legibility  criterion,  although  some 
illustrations  may  be  smaller  if  they  can  be  increased  in  size 
with  t ho  zoom  control.  The  level  of  detail  applicable  to  text 
is  that  equivalent  to  Track  3.  Only  one  level  of  detail  is  used 
for  reference  pool  data. 

Technicians  will  generally  not  use  reference  pool  data  in  the 
normal  course  of  performing  maintenance,  and  only  will  see  it  if 
they  specifically  request  some  portion  of  it,  either  intentionally 
or  by  ri stake,  or  if  they  are  scanning  the  TO  in  the  review  mode. 
Requests  for  reference  data  can  be  made  via  the  user  request  mode 
or,  :n  the  standard  mode,  via  the  general  table  of  contents  or 
(for  some  data)  an  options  list.  The  guidelines  which  have  been 
described  for  other  types  of  data  in  the  data  base  are  generally 
applicable  to  pool  reference  data  for  equivalent  formats.  The 
remainder  of  this  section  illustrates  some  of  the  more  common 
types  of  pool  reference  data  and  discusses  features  which  may  be 
unique . 

5.2  LIST  OR  EFFECTIVE  FRAMES  ( LOEF ) 

•’hi  s  format  is  equivalent  to  the  List  of  Effective  Pages  (LOEP) 
which  is  required  in  all  TOs.  While  the  LOEP  has  some  utility 


to  a  technician  who  is  inserting  change  pages  in  a  TO,  the  LOEF 
will  have  very  limited  use  and  may  be  one  of  the  types  of  infor¬ 
mation  which  can  be  eliminated  by  a  VAMIS-type  system  insofar  as 
display  to  the  users  is  concerned.  The  data  will  still  be 
needed  by  TO  preparers,  and  until  a  contrary  decision  is  made  by 
the  AFTO  System  authorities,  it  should  be  planned  for  inclusion 
in  the  pool  reference  data.  While  the  LOEP  of  a  paper-based  TO 
is  a  simple  itemization  of  the  current  pages  in  a  TO  with  the 
applicable  revision  date  noted,  an  LOEF  should  be  in  two  parts 
to  aid  locating  the  portion  of  the  list  which  is  of  interest. 

The  first  part  should  be  an  index,  as  illustrated  in  the  example 
in  Figure  5-1,  which  provides  a  means  for  going  to  the  LOEF 
frame  containing  the  frame  numbers  of  concern.  This  is  a  simple, 
multi-column  menu  preceded  by  an  explanation  of  the  frame  numbering 
and  change  convention,  as  well  as  instructions  on  how  to  obtain 
the  particular  LOEF  frame  or  an  individual  data  frame.  The 
frame  numbers  encompassed  by  each  line  entry  in  the  LOEF  index 
should  be  broad  enough  to  accommodate  addition  of  new  frames  (as 
new  data  are  added  to  the  TO)  without  having  to  make  changes  to 
the  index.  It  is  not  necessary  that  all  frame  numbers  in  the 
from/to  entry  be  assigned.  The  length  of  the  LOEF  index  will 
depend  on  the  number  of  frames  in  the  TO  and  how  the  frame 
numbers  are  grouped  on  individual  LOEF  frames.  For  large  TOs , 
multiple  index  frames  will  be  needed. 

Individual  LOEF  frames,  an  example  of  which  is  illustrated  in 
Figure  5-2,  are  multi-column  lists  of  the  assigned  frame  codes, 
in  frame  number  order,  with  the  last  issue/revision  date.  They 
are  not  menus,  since  there  is  nothing  appropriate  to  select,  but 
the  use*  can,  if  desired,  step  through  the  LOEF  with  the  FORWARD 
(and  REVERSE)  key.  It  is  not  necessary  for  frame  numbers  to 
be  continuous  on  each  LOEF,  but  when  they  are  non-continuous , 
sufficient  space  should  be  left  in  each  LOEF  for  later  additions 
without  having  to  reorganize  the  entire  LOEF. 
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Figure  5-1 •  Example  of  VAMIS  List  of  Effective  Frames 
index  frame. 


5.3  RECORD  OF  APPLICABLE  TIME  COMPLIANCE 
TECHNICAL  ORDERS  (TCTOs) 


TCTOs  are  a  special  category  of  Technical  Orders  which  provide 
instructions  for  accomplishing  or  making  a  record  of  "one  time 
changes  to  standard  systems  and  equipment  or  for  imparting 
precautionary  instructions  relating  to  safety,  limitations,  or 
inspections  of  systems/equipment  or  munitions.  Compliance  is 
required  within  specified  time  limits.  TCTOs  are  numbered  in 
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Figure  5-2.  Example  of  VAMIS  List  of  Effective  Frames  frame 


the  same  manner  as  basic  TOs,  with  the  last  "dash  number" 
generally  being  -501  or  above.  TCTOs  may  be  included  in  the 
automated  system  or  may  be  in  hard  copy  only.  If  in  VAMIS, 
they  may  be  incorporated  in  the  procedures  section,  the  pool 
section,  or  both  depending  on  the  nature  of  the  instruction  and 
what  is  to  be  accomplished.  Each  TO  which  is  affected  by  the 
issuance  of  a  TCTO  includes,  as  part  of  the  front  matter,  a 
record  of  applicable  TCTOs.  For  a  VAMIS  program,  this  will  be 
included  in  pool  reference  data.  Figure  5-3  illustrates  an 
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example  of  the  applicable  format.  This  format  is  equivalent  to 
that  used  in  paper-based  TOs  with  the  exception  that  a  means  of 
selecting  and  obtaining  the  applicable  TCTO  is  provided  if  the 
TCTO  is  in  the  data  base. 


5.4  INTRODUCTORY  MATERIALS 


The  scope  of  the  introductory  materials  to  be  included  in  the 
pool  reference  data  portion  of  the  data  base  depends  largely  on 
the  size  and  complexity  of  the  TO.  Introductory  materials  for 
sectionalized  TOs  are  generally  specific  to  the  particular  type 
of  data  found  in  that  section,  and  may  include  cross-references 
to  other  sections  of  the  TO.  In  unsectionalized  TOs  the 
introductory  materials  must  provide  an  overview  of  the  entire  TO 
and  cross-references  to  other  TOs  that  i  ay  be  related.  A  VAMIS 
TO  is,  effectively,  an  unsectionalized  TO  so  the  introductory 
materials  should  be  scoped  accordingly.  The  exception,  as  is 
illustrated  in  the  example  in  Figure  5-4,  is  that  the  TO  may  be 
scaled  based  on  the  model/series  selection  menu,  a  factor  which 
should  be  described  in  the  introductory  materials. 

Other  introductory  materials  may  include  descriptions  of  the 
types  of  maintenance  procedures,  e.g.,  job  guides,  and  trouble¬ 
shooting  procedures,  e.g.,  LTTAs ,  and  how  they  are  used.  Content 
specifications  frequently  require  that  the  introductory  materials 
also  include  an  explanation  of  the  use,  in  AF  TOs,  of  the  terms 
"shall,"  "will,"  "should,"  and  "may,"  as  defined  in  MIL-M-38784. 
In  addition,  the  introductory  materials  could  include  such  data 
as  a  consumable  materials  list  and  a  support  equipment  list.  If 
extensive,  data  of  this  type  could  be  placed  in  separate,  iden- 
t.ifiab]e  "sections"  of  the  TO. 

5.5  GENERAL  DESCRIPTION  FORMATS 

Data  in  this  category  are  sometimes  included  with  introductory 
materials  but  are  more  typically  in  an  identifiable  section  of 
the  TO.  General  description  data  explain,  through  the  use  of 
both  text  and  illustrations,  what  the  system  and  its  major 
subsystems/assemblies  consist  of  and  how  they  relate  to  each 


5.6  GLOSSARIES 


A  glossary  is  not  normally  found  in  AF  Technical  Orders, 
although  it  is  quite  common  in  technical  reports  and  in  some 
specifications.  TOs  do  have  a  counterpart  to  a  glossary,  however, 
ir.  the  definition  of  terms  (or  explanation  of  terms)  section, 
usually  a  part  of  the  introductory  materials.  This  section 
normally  contains  only  unusual  terms  which  the  authors  of  the  TO 
have  reason  to  think  may  be  unfamiliar  to  the  user.  The  definition 
of  terms  section  is  usually  quite  brief  and,  in  sectionalized 
TOs,  applies  only  to  the  technical  materials  in  that  section. 

In  a  VAMIS  TO,  the  glossary  will  often  be  quite  comprehensive 
since  it  will  apply  to  all  of  the  technical  materials  in  the 
entire  TO,  and  the  reference  user  will  be  the  Track  3  technician. 

Glossaries  are  accessed  either  from  the  general  TCC  or  from  any 
options  list.  In  either  case,  when  selected  by  the  user,  the 
first  frame  displayed  should  identify  the  type  of  material  in 
that  part  of  the  data  base,  and  provide  guidance  to  the  user  fox- 
obtaining  the  specific  data  of  interest.  Figure  5-6  illustrates 
an  example  of  a  VAMIS  glossary  introductory  frame.  If  the 
glossary  is  lengthy,  as  will  often  be  true  with  TOs  for  complex 
systems,  the  user  should  be  able  to  "jump"  to  a  particular  part 
of  the  glossary,  in  addition  to  "paging"  through  it.  The 
example  shown  assumes  a  very  lengthy  glossary,  and  the  input 
of  two  characters  of  the  term  should  enable  the  user  to  "jump" 
to  within  a  few  frames  of  the  terms  desired.  In  glossaries  ■  f 
medium  length,  using  the  NEXT  SEQUENCE  key  or  inputting  only 
the  first  character  may  be  sufficient.  Alternatively,  it  may  be 
feasible  for  some  limited  glossaries  to  list  the  terms  as  a  menu 
(in  alphabetical  order)  on  the  glossary  introduction  frame  and 
allow  the  user  to  select  the  specific  term  desired. 


Figure  5-6.  Example  of  VAMIS  glossary  introduction  frame. 


The  glossary  frame  itself  has  no  unusual  characteristics,  as 
shown  in  the  example  in  Figure  5-7.  The  term  should  stand  out 
from  the  explanatory  text,  which  should  be  indented.  The  text 
should  briefly  explain  what  the  term  means  in  the  context  of 
the  TO  and  the  maintenance  activities  encompassed.  (Note: 
Entries  in  this  example  frame  are  intended  to  be  illustrative  of 
format  only;  they  are  not  intended  to  establish  guidelines  for 
content  or  level  of  detail  of  the  explanations.)  A  glossary 
frame  can  include  more  than  one  term,  but  the  explanation  for 
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that  term  should  be  complete  on  the  frame  on  which  it  st.  ts. 

When  more  than  one  term  is  on  a  frame,  the  terms  should  be  in 
alphabetical  order.  Similarly,  when  the  user  is  paging  through 
the  ulossary,  the  terms  should  appear  in  alphabetical  order. 
Glossary  frames  will  very  rarely,  if  ever,  include  illustrations. 
If  an  illustration  is  needed,  it  should  accompany  the  term's 
explanation,  precedir. any  ether  term  on  the  same  frame.  When 
the  explanation  of  a  term  must  include  the  use  of  another  term 
which  may  be  equally  unfamiliar  to  the  user.  Key  Codes  can  be 
incorporated  in  the  text  to  provide  a  shortcut  method  of 
obtaining  the  explanation  of  the  second  term.  However,  this 
should  generally  be  avoided. 

5.7  INDEXES 

Very  few  AF  Technical  Orders  contain  an  index.  In  part  this  is 
because  TOs  are  sectionalized  if  they  are  covering  large,  complex 
systems  and  the  resulting  TO  would  be  very  lengthy  if  everything 
was  combined  in  one  "package."  Each  sectional  TO  has  its  own  TO 
number  and  TOC,  easing  the  difficulty  of  locating  a  particular 
kind  of  data.  The  difficulty  level  increases  rapidly,  however, 
if  data  from  more  than  one  sectional  TO  are  needed  for  the  same 
job.  This  is  a  frequent  cause  of  complaints  and  problems 
experienced  by  technicians.  VAMIS  will  include  an  index  for  all 
but  the  simplest  TOs.  Although  many  "aids"  have  been  factored 
into  the  baseline  system  design  and  format  construction  to 
assist  users  in  finding  a  particular  piece  of  information,  there 
is  still  a  risk  of  getting  lost.  Further,  it  should  not  always 
be  necessary  for  a  technician  who  has  finished  a  task  and  wants 
some  other  unrelated  data  to  go  back  to  the  general  TOC  and 
follow  the  normal  accessing  procedure.  In  fact,  use  of  the 
index  is  a  reasonable  alternative  to  the  normal  accessing 
approach  to  entering  the  data  base  once  4  le  technician  has 
selected  a  TO. 
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performance. 
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Of  SIMILAR  OR  IDENTICAL  PURPOSES:  AND  (?)  IS  CAPABLE  OF  BEING  EXCHANGED  FOR  ThE  CTnCP 
ITEM  (A)  WITHOUT  SELECTION  FOR  FIT  OR  PE RF ORMArjC E  .  AND  (B)  WITHOUT  ALTERATION  OF  Th£ 
1UM$  THtMSlLVlS  OR  OF  ADJOINING  ITEMS,  EXCEPT  FOP  ADJUSTMENT. 

ITEM.  INTERCHANGEABLE:  SEE  ‘INTERCHANGEABLE  ITEM"  ON  THIS  FRAME. 

HEP,  REPLACEMENT:  ONE  WHICH  IS  INTERCHANGEABLE  WITH  ANOTHER  MEM,  BUT  WHICH  DIFFERS 

PHYSICALLY  FRO-  The  ORIGINAL  m**  in  that  THE  INSTALLATION  of  the  REPLACEMENT  ITf 
REQUIRES  OPERATIONS  SUCH  AS  DRILLING.  REAMING,  CUTTING.  FILING.  ShIMING,  ETC..  I  n 
ACCITJO*.  TO  THE  NORMAL  APPLICATION  AND  METHODS  OF  ATTACHMENT. 

!’[•*.  SUBSTITUTE  ONE  WhJCh  POSSESSES  SUCH  FUNCTIONAL  AND  PHYSICAL  CHARACTERISTICS  AS  ”  fcf 
CAPAS. I  OF  BEING  EXCHANGED  FOR  ANOTHER  ONLY  UNDER  SPECIFIED  CONDITIONS  0«  IN  FX**;... 
L»P  APPLICATIONS  Af.O  WITHOUT  ALTERATION  Of  THE  1T£M$  THEMSELVES  OR  Of  ADJOINING  l‘E*". 

HOFCU  INTERIM  TECHNICAL  ORDER  FIELD  CHANGE  NOTICE  [A). 


BFOR  NEXT  FRAME:  [FORWARD]. 
FOR  REFERENCED  TERMS:  1HPU 


REFERENCED  TERMS:  INPUT  MY  CODE  [  V.  UnTER} 


Figure  5-7.  Example  of  VAMIS  glossary  frame. 

As  with  glossaries,  indexes  are  accessed  either  from  an  options 
list  or  from  a  general  TOC.  The  first  frame  of  the  index  should 
be  an  introduction  and  guidance  frame,  the  format  of  which  is 
the  same  as  the  glossary  introduction  frame  illustrated  in 
Figure  5-6. 


Index  frames  should  be  a  type  of  menu,  from  which  the  user  can 
select  the  particular  type  of  information  needed.  As  shown  in 
the  example  in  Figure  5-8,  a  VAMIS  index  will  differ  in  several 


ways  from  an  index  such  as  might  be  found  in  a  technical  report 
or  specification.  First,  it  is  not  necessary  to  list  an  index 
reference  for  each  utilization  of  a  particular  term  or  name. 

A  particular  component  might  be  named  in  every  frame  of  data  for 
a  procedural  task.  Providing  an  index  reference  to  each  such 
entry  would  not  only  be  irrelevant,  it  would  make  use  of  the 
index  so  cumbersome  that  its  purpose  would  be  defeated.  What  is 
needed  is  to  list  the  name  of  each  such  component  in  the 
appropriate  context  of  its  relationship  to  the  data  of  which  it 
is  a  part.  When  selection  is  made,  the  system  accesses  the 
fir  it  frame  of  the  appropriate  series  of  data. 

Secondly,  the  index  will  net  contain  any  page  numbers,  or  other 
usual  types  of  location  references.  Not  only  are  page  numbers 
v'.c.,  frame  numbers)  of  no  use  to  the  technician  in  this  appli¬ 
cation,  but  the  actual  data  to  be  supplied  will  depend  on  the 
authorized  Track  level  of  the  user.  A  Track  3  technician  cannot 
use  the  index  to  request  a  frame  of  data  which  is  only  authorized 
for  use  by  Track  1  technicians,  for  example. 

1  r:  addition,  the  index  entries  must  be  sufficiently  descriptive 
of  t  iie  context  so  that  the  user  can  be  reasonably  certain  when  a 
selection  is  made  that  it  represents  the  portion  of  data  needed. 
Snco  a  selection  is  made,  and  the  data  accessed,  the  user  cannot 
easily  return  to  the  same  index  frame  in  order  to  make  another 
selection  (but  see  Subsection  5.8,  below). 

Index  entries  should  be  easily  identifiable,  and  should  consider 
ear h  way  in  which  a  user  might  reasonably  expect  to  find  it. 

Thus  official  nomenclature  such  as  "Auxiliary  Cross  Track  Control 
Indicator"  should  also  be  entered  in  the  index  as  "Cross  Track 
Control  Indicator,  Auxiliary,"  "Control  Indicator,  Auxiliary 
Cross  Track,"  and  "Indicator,  Control,  Auxiliary  Cross  Track." 


The  "official"  entry  should  contain  all  of  the  context  references 
for  accessing  the  data.  All  other  alternate  entries  should, 
when  selected,  access  the  official  entry  frame  if  there  are  two 
or  more  different  context  listings.  If  there  is  only  one  item 
of  data  available,  it  is  more  efficient  to  provide  the  data  than 
to  cross-reference  all  the  nomenclature  variations. 
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If  a  particular  entry,  e.g.,  "Procedures"  in  the  example  in 
Figure  5-8,  would  require  a  lengthy  list  of  data  for  that 
heading,  a  special  index  should  be  provided  for  users  who  want 
that  heading.  This  will  preclude  other  users  from  having  to 
page  through  numerous  frames  in  order  to  reach  a  term  starting 
with  the  same  characters;  e.g.,  "Protective  packaging." 

.;  .  b'  t  PER  RECORD 

Tins  type  of  information  has  no  counterpart  in  paper-based  TOs , 
unless  one  considers  the  individual  methods  used  by  technicians 
to  identify  the  location  of  a  particular  drawing  or  schematic 
within  the  TO  (e.g.,  attaching  a  paper  clip  to  a  page,  turning 
down  a  corner,  wr-ting  the  page  number  on  a  piece  of  paper)  or 
keeping  track  of  progress  (e.g.,  checking  off  in  the  margins) . 

A  VAMJS-type  system  has  the  unique  capability  for  keeping  track 
of.  the  requests  made,  frames  displayed,  and  other  such  factors 
during  the  period  of  use.  Indeed,  it  must  keep  track  of  many  of 
these  factors  in  order  that  it  can  respond  to  control  inputs 
such  as  RETURN,  REPEAT  SEQUENCE,  and  RELEASE  FROM  SHOW.  This 
capability  can  be  used  to  provide  valuable  information  to  both 
the  individual  user  and  the  automated  system  managers.  It  may 
also  be  useful  for  upgrading  technician  skills  through  formal 
training  and  OJT. 

8  .  .  1  Individual  U se  of.  User  Record 

The  user  record,  an  example  of  which  is  illustrated  in  Fiaure  5- 
prosents  a  step-by-step  record  of  a  user's  progress  through  the 
data  base,  identifying  the  frames  of  information  that  were 
presented  and  the  control  inputs  that  were  made.  Header  infor¬ 
mation  identifies  the  user  (but  not  the  user's  authorization 
coco) ,  the  time  logged  on  the  system,  and  the  user  record  frame 
sequence  number.  If  it  is  a  second  or  subsequent  user  record 
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frame,  it  also  shows  the  time  that  each  new  record  frame  was 
started.  In  this  example,  a  frame  code  beginning  with  9AA  is 
assigned,  since  that  series  is  not  used  for  frame  identification. 
While  the  frame  code  has  no  value  to  the  user  in  this  application 
it  may  be  useful  for  maintainance  supervisors  and  training 
officers  for  reaccessing  user  records. 
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Figure  5-9.  Example  of  VAMIS  user  record  frame 


An  individual  user  could  access  his  own  user  record  via  the 
options  list.  It  would  show  only  the  record  of  activity  of  that 
user  from  the  point  of  signing  on  the  system  for  the  current 
period  of  use.  If  the  user  signs  off  the  system,  his  or  her  user 
record  is  no  longer  available  in  this  manner  (but  see  para¬ 
graph  5.8.2,  below).  The  example  in  Figure  5-9  illustrates  a 
hypothetical  record  of  a  technician's  movement  through  the  data 
base,  documenting  each  control  action  and  the  system  response  to 
that  action.  The  record  also  provides  clues  of  the  points  at 
which  errors  were  made,  or  poor  choices  were  exercised.  (See 
sequence  numbers  61,  62,  70,  80  (selected  maintenance  parts  list 
when  the  breakdown  illustrated  was  wanted) ,  84  (input  PA  instead 
of  BA,  for  BAckrest) ,  85  (got  impatient  and  ended  up  back  in  the 
Procedures).)  It  also  shows  how  the  technician  used  the  user 
record  to  determine  what  should  have  been  done  (88,  89),  reviewed 
how  to  use  the  IPB,  and  obtained  the  desired  data  to  finish  the 
task . 

Users  could  request  their  user  record  if  they  simply  wanted  to 
review  where  they  had  been  within  the  data  base,  but  are  more 
likely  to  access  it  as  a  way  of  identifying  the  point  at  which 
they  "got  lost,"  then  using  that  information  for  getting  back  to 
where  they  want  to  be.  It  may  also  be  useful  to  help  identify 
where  a  mistake  was  made  (e.g.,  responding  with  a  YES  when  the 
correct  troubleshooting  response  to  a  logic  tree  question  was 
NO).  It  may,  in  addition,  provide  a  shortcut  for  reaccessing  a 
frame  of  pool  data  without  going  through  a  long  menu  selection 
process. 

when  the  individual  user  logs  off  the  system,  the  computer 
registers  the  log-off  action  and  time,  and  the  record  is  no 
longer  available  through  normal  accessing  procedures. 


5.8.2  Management  Use  of  User  Records 


As  stated  above,  when  the  individual  logs  off  the  system,  the 
user  record  is  no  longer  available  through  normal  procedures. 

It  is  planned,  however,  that  individual  user  records  be  retained 
in  the  system  memory  for  a  period  of  time  for  use  by  supervisory 
personnel  and  training  staff,  where  applicable.  While  no  firm 
plan  exists  in  this  program  for  such  a  capability,  it  is 
envisioned  that  being  able  to  call  up  the  user  records  for 
individual  technicians  could  be  a  valuable  capability.  When 
performance  problems  are  encountered,  an  individual's  user 
record  file  could  be  reviewed,  possibly  with  the  individual,  to 
try  to  determine  sources  of  the  problems  and  corrective  measures 
which  are  needed.  Similarly,  supervisory  or  training  staff 
could  evaluate  user  records  to  assist  in  identifying  areas  where 
improvement  through  training  would  be  appropriate,  or  when 
technicians  have  become  proficient  enough  to  warrant  changing 
the  authorized  Track  level.  User  record  files  could  also  be 
printed  in  hard  copy  for  long-term  storage,  releasing  the  frame 
space  for  new  user  records. 


SECTION  6.0 

PROCEDURAL  SUPPORT  POOL  DATA 


6.1  INTRODUCTION 

Procedural  support  pool  data  are  defined  as  that  data  and  infor¬ 
mation  ".  .  .  which  are  used  primarily  to  amplify  or  clarify  a 
specific  maintenance  or  troubleshooting  procedure,  or  otherwise 
assist  ir.  accomplishing  a  task"  (see  paragraph  2.4.1).  This 
definition  can  include  a  broad  spectrum  of  information  found  in 
TOs  since  almost  any  portion  of  a  TO  can  be  used  for  procedural 
support  under  some  circumstances.  Conversely,  data  that  fit 
this  definition  may  also  have  other  uses  which  are  unrelated  to 
support  of  a  maintenance  procedure. 

In  VAMIS,  procedural  support  pool  data  comprise  the  following: 

a.  Illustrated  Parts  Breakdown  (IPB) 

b.  Function  Diagrams 

c.  Other,  e.g.,  Access  and  Locator  Diagrams,  Test  Setup 
Instructions,  and  Test  Specifications. 

It  is  anticipated  that,  while  these  data  types  will  be  used  for 
support  of  maintenance  and  troubleshooting,  in  some  cases  Track  1 
technicians  will  access  this  type  of  information  as  the  primary 
basis  for  task  performance. 

6.2  ILLUSTRATED  PARTS  BREAKDOWN  (IPB) 

6.2.1  General  Format  Considerations 

In  the  AFTO  System,  the  IPB  for  an  equipment  system  may  be  a 
separate  section,  or  chapter,  of  the  basic  maintenance  TO  or  it 
may  be  a  completely  separate  TO,  with  its  own  TO  number.  In 


the  latter  case,  the  TO  containing  the  IPB  would  be  numbered  as 
"-4"  for  the  basic  TO,  replacing  the  maintenance  level  designation 
When  packaged  as  a  section  of  the  basic  TO,  the  IPB  has  the  same 
maintenance  level  designation  as  the  TO  of  which  it  is  a  part 
(e.g.,  -2  for  organizational;  -3  for  intermediate).  IPBs  are 
not  normally  associated  with  organizational  level  TOs. 

VAMIS  IPBs  will  be  considered  as  a  section  of  the  basic  TO  and 
carry  the  same  maintenance  level  designation.  This  will  permit 
the  IPB  to  be  accessed  directly  from  the  related  maintenance 
level  TO  without  calling  up  a  different  TO  number.  However, 
since  the  IPB  for  a  -2  and  a  -3  maintenance  TO  for  a  system  are 
likely  to  have  identical  contents,  it  is  acceptable  to  designate 
the  IPB  as  a  -4  TO  if  the  direct  access  (and  return)  requirements 
can  be  satisfied  through  software.  The  latter  approach  will 
permit  preparation  of  a  single  IPB  to  support  both  levels  of 
maintenance,  even  if  they  are  not  performed  at  the  same  site. 

All  portions  of  the  IPB  data  will  have  the  parts  breakdown 
designation  in  the  frame  code.  All  parts  breakdown  frames  are 
prepared  according  to  Level  3  viewing  criteria.  Portions  of  any 
parts  breakdown  frame  which  are  composed  of  illustrations  are 
subject  to  the  screen  controls  on  the  control  unit. 

Air  Force  IPBs  are  required  to  be  prepared  in  accordance  with 
specification  MIL-M-38807  (USAF) ,  which  imposes  both  format  and 
content  requirements.  In  general,  VAMIS  IPBs  comply  with  these 
requirements,  but  some  variations  in  format  are  needed.  The 
principal  reason  for  the  variance  is  that  paper-based  IPBs 
frequently  require  using  data  from  two,  or  more,  parts  of  the 
IPB  at  the  same  time.  Since  the  baseline  VAMIS  does  not  have 
dual  screens  for  side-by-side  presentations  of  such  related 


data,  a  new  format  called  a  Composite  Parts  Breakdown  (CPB)  has 
been  devised  to  meet  the  same  objectives.  All  other  "parts"  of 
the  IPB  are  represented  in  the  VAMIS  IPB  in  formats  similar  to 
those  in  paper-based  TOs. 

6.2.2  Contents  and  Data  Access 

USAF  IPBs  consist  of  several  "parts,"  each  containing  usable 
data  and  cross-references  to  another  part.  In  this  way  a  user 
can  work  to  a  particular  page  which  may  contain  all  of  the 
information  needed,  or  may  use__£he  cross-references  to  access 
individual  pages  in  more  than  oneXpart  and  use  them  together. 

The  path  followed  by  the  user  depends  on  the  identifying 
information  already  in  hand  and  the  type(s)  of  information 
needed. 

The  VAMIS  IBP  concept  is  similar,  but  with  several  significant 
differences.  The  path  followed  by  the  user  is  still  based  on 
what  is  already  known.  However,  the  path  will  always  lead  to  a 
Composite  Parts  Breakdown  (CPB)  for  the  item  of  interest,  where 
all  useful  information  is  presented  on  one  frame.  The  other 
parts  have  been  converted  to  intermediate  steps  in  the  path. 
Figure  6-1  illustrates  the  principal  types  of  data  in  a  VAMIS 
IPB  and  the  pathways  available  in  both  the  standard  and  user 
request  modes  of  use.  The  VAMIS  IPB  contains  the  same  types  of 
front  matter  and  introductory  materials,  plus  various  lists, 
indexes,  and  illustrations  configured  to  lead  the  user  to  the 
needed  data  in  the  correct  CPB.  In  some  instances  the  technician 
may  stop  short  of  the  CPB  (e.g.,  at  a  breakdown  illustration)  if 
the  need  for  information  has  been  satisfied.  As  can  be  seen,  the 
knowledgeable  user  can  eliminate  many  intermediate  steps  in  the 


user  request  mode. 


6.2.3  Front  Matter  and  Introductory  Materials 


VAMIS  IPBs  will  contain  all  of  the  same  front  matter  and 
introductory  materials  necessary  for  compliance  with  MIL-M-38807 
(USAF) .  Although  some  of  these  materials  will  be  necessary 
intermediate  steps  in  the  standard  mode,  most  will  have  to  be 
intentionally  selected  by  the  user  in  either  the  standard  or 
user  request  mode. 

6. 2. 3.1  Title  Frame  and  Table  of  Contents.  An  IPB  title  frame, 
an  example  of  which  is  illustrated  in  Figure  6-2,  is  the  first 
frame  which  will  be  displayed  to  standard  mode  users,  either 
from  a  TO  general  TOC  or  an  options  list.  Guidelines  for 
formatting  of  title  frames  are  discussed  in  paragraph  4.3.2.  In 
addition  to  its  obvious  function  of  identifying  the  discrete 
portion  of  the  TO  which  the  user  has  accessed,  the  title  frame 
also  includes  a  top-level  IPB  TOC  for  those  who  know  what  data 
they  want  and  how  to  interact  with  a  VAMIS  IPB.  Users  who  are 
less  certain  of  what  they  want  may  select  the  IPB  TOC.  Those 
who  are  not  sure  how  to  obtain  what  they  need  should  select  the 
"How  To  Use  This  IPB"  section. 

An  example  of  a  VAMIS  IPB  TOC  is  illustrated  in  Figure  6-3. 
Guidelines  for  IPB  TOC  preparation  are  the  same  as  for  other 
TOCs  except  that  the  level  of  detail  for  the  major,  non- 
introductory ,  parts  of  the  IPB  is  purposely  limited.  This 
is  to  ensure  that  the  user  who  accesses  any  of  these  IPB 
parts  begins  at  the  appropriate  first  frame  for  that  part. 
Consequently,  the  IPB  TOC  is  most  useful  to  individuals  who  want 
information  about  the  IPB  from  the  introductory  materials. 

6. 2. 3. 2  How  To  Use  a  VAMIS  IPB.  Paper-based  IPBs  generally 
contain  one  or  more  pages  of  guidance,  especially  directed  at 
new  users,  for  obtaining  a  particular  piece  of  IPB  information 
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Figure  6-3.  Example  of  VAMIS  IPB  TOC  frame. 

need  only  to  refer  to  the  diagram  for  purposes  of  selecting 
a  path  since  the  prompts  on  each  frame  will  guide  them  to 
completion  if  they  know  what  they  want.  The  new  user  of  a 
paper-based  IPB  may  need  to  continually  look  back  at  the 
decision  flow  diagram  to  determine  what  the  next  step  should 
be. 


6. 2. 3. 3  Other  Introductory  Materials.  The  remaining  materials 
in  the  IPB  are  intended  to  explain  IPB  contents,  terms,  and 


Figure  6-4.  Example  of  VAMIS  "How  To  Use  This  IPB"  frame. 

sources  of  data  in  the  IPB.  The  TOC  example  in  Figure  6-3 
identifies  the  types  of  explanations  to  be  included.  Users 
may  review  these  materials  in  sequence  to  gain  an  overall 
understanding  of  the  IPB,  or  may  select  (from  the  TOC)  a 
particular  topic  for  review.  An  example  of  one  such  topic, 
explaining  "usable-on  codes,"  is  illustrated  in  Figure  6-5. 
Note  that,  as  explained  in  the  example,  VAMIS  IPBs  do  not  use 
a  master  list  of  usable-on  codes  as  found  in  some  paper-based 
IPBs,  in  order  to  avoid  the  necessity  for  referring  back  to  th 


the  information  needed.  Paper-based  counterparts  somewhat  serve 
the  purpose,  but  also  include  some,  but  not  all,  of  the  useful 
data  which  may  be  sought.  As  explained  in  the  bottom  portion  of 
the  "How  To  Use"  frame  (Figure  6-4) ,  this  information  is  termed 
"application  data"  in  a  VAMIS  IPB.  There  are  five  basic  types  of 
intermediate  selection  frames: 

a.  Reference  designation  index 

b.  Part  number  index 

c.  Major  assemblies  list 

d.  Maintenance  parts  list 

e.  Breakdown  illustration. 

The  characteristics  of  each  type,  and  its  role  in  obtaining  the 
applicable  CPB,  are  discussed  below. 

6. 2. 4.1  Reference  Designation  (RD)  Index.  One  of  the  most 
common  ways  of  entering  an  IPB  is  with  a  reference  designation 
as  the  "known  information."  The  technician  may  want  to  obtain 
the  equivalent  part  number,  a  breakdown  illustration,  some 
selected  application  data,  or  some  combination.  Several  types 
of  paper-based  RD  indexes  were  illustrated  in  Figure  2-14. 
VAMIS-type  IPBs  will  normally  have  two  types  of  RD  index  frames: 
an  RD  master  index  and  an  RD  index. 

When  the  number  of  individual  RD  index  frames  will  exceed  10,  the 
first  frame  of  the  sequence  will  be  an  RD  master  index  as  illus¬ 
trated  in  Figure  6-6.  An  RD  master  index  reduces  the  number  of 
individual  index  frames  which  a  technician  will  need  to  step 
through  to  find  the  correct  one.  Each  line  entry  in  the  master 
index  coincides  with  the  first  entry  on  an  individual  RD  index 
frame.  If  feasible,  the  master  index  should  be  complete  on  one 
frame,  and  each  major  group  of  RDs  should  start  on  a  new  line, 


preferably  with  a  blank  line  preceding  it,  or  start  a  new 
column.  Note  that,  in  the  example,  RD  11  (at  key  code  21)  is 
not  out  of  sequence  according  to  the  IPB  specification  require¬ 
ments  for  sequencing.  Recognition  by  technicians  would 
probably  be  enhanced  if  "eleven"  was  in  conventional  numerical 
sequence,  but  sequencing  would  then  be  different  from  paper-based 
IPEs. 


Figure  6-6.  Example  of  VAMIS  IPB  reference  designation 
index,  master  index  frame. 


The  technician  who  has  chosen  this  path  will  select  the  key  code 
opposite  the  appropriate  RD  on  the  master  index  to  obtain  a 
specific  RD  index  frame.  An  example  is  shown  in  Figure  6-7. 

Each  such  frame  lists  all  of  the  system  RDs  within  the  group  in 
proper  sequence.  Selection  of  the  key  code  adjacent  to  the 
known  RD  will  in  most  cases  access  the  appropriate  CPB. 
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In  a  relatively  limited  number  of  cases  the  system  will  be 
unable  to  provide  the  correct  CPB  because  of  multiple  use  of  a 
single  HD  for  different  equipment  configurations.  For  such 
cases  an  RD  multiple  use  index  frame  is  inserted  in  the 
sequence.  An  example  is  depicted  in  Figure  6-8.  This  example 
depicts  a  particularly  complex  case  based  on  configurations  in 
the  reference  IPB,  so  the  format  should  satisfy  all  foreseeable 
applications.  In  less  complex  cases,  the  boxed  area  in  the 
example  could  contain  more  than  one  target  RD,  as  long  as  the 
list  of  next  higher  assemblies  (NHAs)  is  compatible. 
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Figure  6-8 


6. 2. 4. 2  Part  Humber  (PN)  Index.  An  approach  to  obtaining  IPB 
information  which  is  as  common  as  the  RD  index  is  through  a  PN 
index.  An  example  of  a  paper-based  PN  index  was  illustrated  in 
Figure  2-13.  In  an  approach  similar  to  that  described  for  the 
RD  index,  when  the  number  of  individual  PN  index  frames  will 
exceed  10,  a  PN  master  index  frame  is  used  as  illustrated  in 
Figure  6-9.  PN  entries  on  each  line  coincide  with  the  first  PN 
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Figure  6-9.  Example  of  VAMIS  IPB  part  numbers  master 
index  frame. 


index  frame.  PNs  beginning  with  alphabetic  characters  precede 
those  beginning  with  integers.  Selection  of  the  key  code  adjacent 
to  the  applicable  beginning  PN  will  yield  the  appropriate 
individual  PN  index  frame,  an  example  of  which  is  presented 
in  Figure  6-10. 
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Selection  of  the  applicable  key  code  for  the  known  part 
number  will  normally  access  the  CPB  for  that  PN,  unless  the 
particular  part  with  that  PN  has  more  than  one  application  or 
use  within  the  system.  In  the  latter  case,  a  multiple  appli¬ 
cation  PN  index  (MAPNI)  frame  is  inserted  in  the  sequence. 

This  format,  an  example  of  which  is  illustrated  in  Figure  6-11 
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018656-80?  .  CIRCUIT  CARD  ASST.  INDICATOR  BOAR;  3 

016431-00?  .  CIRCUIT  CARD  ASST.  INDICATOR  BOARD  4 


c  . . : . . . . 


is  used  whenever  a  selected  PN  has  multiple  applications  that 
would  result  in  more  than  one  CPB.  As  will  be  shown  later  in 
this  section,  however,  the  CPB  format  has  some  flexibility  for 
incorporating  multiple  application  PNs;  it  will  not  always  be 
necessary  to  insert  a  MAPNI.  As  a  general  rule,  if  the  PN  has 
more  than  one  equivalent  RD  and  more  than  one  figure/index  number 
in  the  same  NHA,  plan  on  separate  CPBs  selected  via  a  MAPNI.  If 
the  PN  has  multiple  RDs  with  the  same  figure/index  number,  they 
can  usually  be  combined  in  a  single  CPB. 

6.2.4. 3  Major  Assemblies  List  (MAL) .  This  format  is  primarily 
for  individuals  who  do  not  know  either  the  RD  or  the  PN  of  the 
part,  but  are  familiar  with  the  names.  As  is  depicted  in 
Figure  6-1,  it  may  also  be  the  preferred  route  for  users  who 
want  to  obtain  a  breakdown  illustration  but  do  not  need  the  data 
on  a  CPB.  An  example  of  the  major  assemblies  list  format  is 
shown  in  Figure  6-12.  It  is  actually  a  simple  menu  of  the 
major  assemblies  which  make  up  the  system  or  equipment,  and  for 
which  maintenance  parts  lists  (MPL)  and  breakdown  illustrations 
(BI)  are  provided  in  the  IPB.  It  is  this  relationship  to  MPLs 
and  Bis  which  gives  the  MAL  its  only  unusual  feature:  Two 
selection  columns  are  provided,  giving  the  user  a  choice  of  path 
to  the  CPB.  Technicians  who  are  more  familiar  with  the  nomen¬ 
clature  would  select  the  MPL;  those  who  are  more  familiar  with 
configuration,  or  simply  want  an  illustrated  breakdown  would 
select  BI.  Although  many  MALs  will  be  complete  on  one  frame, 
it  will  not  be  unusual  for  complex  system  MALs  to  continue  on 
second  and  subsequent  frames.  When  this  occurs,  the  numbers  in 
the  figure  number  column  should  be  consecutive  through  the  series 
of  frames,  coinciding  with  the  actual  figure  numbers  of  the 
applicable  BI.  Key  codes,  on  the  other  hand,  are  arbitrary 
codes  and  should  start  over  on  each  new  frame. 
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ejection  SCAT  ACRERAL  installation 

mors  arc  radar  mors  rocket  assist  ejection  seat  assembly. 
PILOT'S  aro  radar  pilot's  ejection  seat  assembly. 

SCAT  CUSHION  ASSEMBLY. 

ejectior  aur  assembly . 

OROAUE  AUR  ASSEMBLY. 

TIME  RELEASE  MECHANISM  ASSEMBLY. 

SEAT  ROSITION  ACTUATOR  ASSEMBLY. 

SEAT  ASSEMBLY. 

BACKREST  ! RST AllAT ION . 

f ACE  SCREEN  ASSEMBLY. 

AulLLOT IRE  AND  R I R I  NS  INSTALLATION. 

TOP  ATTACHMENT  MECHANISM  ASSEMBLY. 

SEAT  BUCKET  FINING  CONTROL  ASSEMBLY. 

manual  override  and  led  restraint  mechanism  assembly. 

SHOULDER  HARNESS  ADJUSTMENT  MECHANISM  ASSEMBLY. 
seat  bucket  assembly. 

FOHnARD  AND  APT  canopy  interrupts  mechanism  assembly. 

OROCUE  PARACHUTE  CONTAINER  ASSEMBLY. 

MAIN  beam  assembly. 

ACTUATOR  HIRING  INSTALLATION. 

EMERGENCY  OKTCER  MECHANISM  ASSEMBLY. 

SPECIAL  TOOLS  KIT. 


D  *0*  breakdown  illustration 

Q  FOR  MAINTENANCE  RAFTS  LIST 


INPUT  FIGURE  NUMBER  [  ).  [[NTfR] 

INPUT  AEY  CODE  [  ].  [ENTER] 


Figure  6-12.  Example  of  VAMIS  IPB  major  assemblies 
list  frame. 

6. 2. 4. 4  Maintenance  Parts  List  (MPL) .  In  paper-based  IPBs  the 
MPL  (formerly  the  group  assembly  parts  list)  is  both  a  source 
of  applications  data  as  well  as  an  index  or  cross-reference  to 
the  associated  breakdown  illustration.  In  VAMIS-type  IPBs  the 
MPL  is  primarily  a  selection  menu,  as  shown  in  Figure  6-13,  for 
obtaining  the  correct  CPB.  Index  codes,  descriptive  nomenclature, 
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indenture,  and  usable-on  codes  used  in  the  MPL  establish  the 
base1 ine  for  related  breakdown  illustrations  and  CPBs.  Part 
numbers  and  usable-on  codes  are  included  to  assist  the  user  in 
selecting  the  correct  part.  The  description  column,  which  is 
primarily  what  technicians  will  use  in  identifying  the  part  of 
interest,  is  in  the  normal  top-down  breakdown,  indentured  organi 
zation.  On  a  continuation  frame,  such  as  would  follow  this 
example  frame,  all  top  (0)  level  entries  must  be  repeated,  as 
well  as  any  lower  indentures  against  which  usable-on  codes  apply 


6. 2. 4. 5  Breakdown  Illustration  (BI) .  Breakdown  illustrations 
in  VAMIS  will  normally  not  differ  greatly  from  those  in  paper- 
based  IPBs ,  as  can  be  seen  in  the  examples  in  Figures  6-14  and 
6-15  (for  a  mechanical  assembly  and  an  electronic  assembly, 
respectively) .  However,  some  large  illustrations,  which  may  be 
on  foldout  pages  in  a  paper  TO,  will  need  to  be  divided  into 
subassemblies,  or  on  some  other  basis,  in  order  to  be  compre¬ 
hensible  on  a  video  screen.  All  parts  which  can  be  illustrated 
should  be  shown  and  should  have  an  index  number  which  is  the 
same  as  on  the  MPL  and  CPB.  Parts  which  are  not  illustrated 
will  normally  have  no  index  number,  but  should,  if  possible,  be 
listed  with  a  code  for  selection  of  the  applicable  CPB.  If  the 
selection  of  a  particular  index  code  could  result  in  more  than 
one  Composite  Parts  Breakdown,  because  of  multiple  part  numbers 
and/or  different  usable-on  configurations,  divert  to  the 
appropriate  reference  designator  multiple  use  index  (index 
numbers,  like  reference  designators,  normally  apply  to  the  part 
in  a  specific  location) .  In  systems  where  RDs  have  not  been 
assigned  (as  in  many  mechanical  assemblies) ,  a  special  multiple 
use  index  may  have  to  be  compiled.  Alternatively,  the  Composite 
Parts  Breakdown  could  list  all  the  alternative  part  numbers  for 
that  use  of  the  index  number.  On  plan  view  breakdown  illus¬ 
trations  such  as  the  example  in  Figure  6-15,  it  is  not  feasible 
to  have  the  index  numbers  meet  the  character  size  requirements 
normally  imposed,  or  to  show  the  code  "brackets"  indicating 
selectability ,  without  degrading  the  illustration's  compre¬ 
hensibility.  The  user  will  need  to  use  the  zoom  feature  to 
increase  character  size.  The  note  at  the  top  of  the  frame 
should  clarify  the  availability  of  index  numbers  for  selection. 

6.2.5  Composite  Parts  Breakdown  (CPB) 

This  format  is  the  working  part  of  a  VAMIS-type  IPB,  and  is 
the  end  result  of  the  selection  methods,  formats,  and  pathways 
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described  above.  Figure  6-16  illustrates  an  example  of  a 
relatively  simple  CPB,  the  result  of  selecting  index  code  11  on 
the  breakdown  illustration  (Figure  6-14)  or  on  the  maintenance 
parts  list.  The  same  CPB  would  result  from  selection  of  PN 
MBEU1486H5  on  the  PN  index  (key  code  23  on  Figure  6-10).  Since 
reference  designations  are  not  used  in  this  system  (normal  for 
mechanical  assemblies) ,  this  CPB  would  have  no  related  RD  index 
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Fiaure  6-14 


Example  of  VAMIS  IPB  breakdown  illustration 
frame  (exploded  view  of  simple  mechanical 
assembly) . 
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Figure  6-15.  Example  of  VAMIS  IPB  breakdown  illustration 
(plan  view  of  electronic  assembly) . 


The  basic  elements  of  a  CPB  are  the  applicable  BI  (or  necessary 
portion  thereof) ,  the  applicable  portion  of  the  MPL  (including 
the  selected  indexed  part,  and  higher  and  lower  assemblies/parts) , 
the  applicable  part  numbers  and  usable-on  codes,  and  the  appli¬ 
cation  data  for  the  indexed  part.  The  listing  for  the  selected 
part  is  highlighted  by  boxing  in  this  example.  Since  no  further 
breakdown  of  the  selected  part  is  available,  the  index  number  is 
coded  as  not  selectable.  If  a  further  breakdown  was  available, 
the  *  *  would  not  be  shown. 
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Figure  6-16. 


Example  of  VAMIS  IPB  Composite  Parts  Breakdown 
(CPB)  frame  (simple  mechanical  assembly  with 
exploded  view) . 


When  the  list  of  next  lower  assemblies  (NLAs )  is  short,  they 
should  be  included  in  the  CPB.  When  the  list  is  lengthy,  provide 
an  index  code  for  next  lower  assemblies.  Selection  of  the  code 
would  go  to  a  new  frame  containing  the  full  list  of  NLAs 
indentured  under  the  part  of  interest  with  an  indexed  breakdown 
illustration,  but  without  the  topdown  breakdown  or  application 
data.  Selection  of  the  index  code  for  one  of  these  NLAs  would 
yield  a  typical  CPB. 
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The  topdown  breakdown  used  in  a  CPB  should  start  no  higher  than 
one  level  above  the  reference  (0)  level,  unless  higher  level 
usable-on  codes  are  involved  and  they  are  necessary  information. 
Attempting  to  construct  a  complete  topdown  breakdown  consumes 
valuable  display  space  and  has  limited  information  value. 

Many  CPBs  may  not  be  as  simple  as  in  the  preceding  example.  To 
illustrate,  the  example  in  Figure  6-17  requires  the  inclusion  of 
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some  "select-at-test"  data  to  determine  the  correct  PN.  Since 
space  on  the  frame  is  available,  the  reference  data  are  included 
on  the  same  frame,  as  shown.  When  this  approach  is  used, 
e.g.,  for  coding  select-at-test  part  numbers,  care  must  be 
taken  that  the  key  codes  do  not  duplicate  index  codes. 

When  the  need  for  provision  of  such  additional  information 
requires  more  space  than  is  conveniently  available  on  a  single 
CPB  frame,  the  referenced  data  are  placed  on  a  supplementary 
frame  which  can  be  directly  accessed  from  the  CPB.  This  approach 
is  illustrated  in  the  examples  in  Figures  6-18  and  6-19. 
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Figure  6-19.  Example  of  VAMIS  IPB  Composite  Parts  Breakdown 
(CPB)  supplementary  data  list  frame. 

Additional  variations  of  the  basic  CPB  format  are  illustrated  in 
Figures  6-20  and  6-21.  Both  examples  are  single-frame  CPBs  which 
illustrate  solutions  to  problem  areas.  Figure  6-20  shows  the 
value  of  the  usable-on  codes  and  the  ability  to  quickly  obtain 
related  CPBs.  Figure  6-21  shows  an  acceptable  approach  to 
providing  a  CPB  for  a  part  which  is  not  illustrated  or  indexed. 
When  new  IPB  data  are  being  prepared,  however,  consideration 
should  be  given  to  indexing  all  parts,  even  if  they  are  not 
illustrated. 


Figure  6-20.  Example  of  VAMIS  IPB  Composite  Parts  Breakdown 
(CPB)  frame  with  multiple  higher  assemblies 
and  parts  of  interest. 

6.3  FUNCTION  DIAGRAMS 

6.3.1  Introduction 

A  general  discussion  of  function  diagrams  is  presented  in 
paragraph  2.4.3,  including  the  scope  intended  by  the  use  of  the 
term  and  the  specification  requirements  which  are  applicable. 

For  purposes  of  VAMIS-type  systems,  all  function  diagrams  are 
classified  either  as  schematic  diagrams  (SD)  or  wiring  diagrams 
(WD) .  All  of  the  samples  illustrated  herein  are  in  the  SD 
category,  but  the  principles  and  guidelines  apply  equally  to  the 
WD  category. 
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Figure  6-21.  Example  of  VAMIS  IPB  Composite  Parts  Breakdown 
(CPB)  frame  for  non-indexed/illustrated 
attaching  parts  (AP) . 


6.3.2  General  Considerations 

Function  diagrams,  probably  more  than  any  other  type  of  information 
found  in  technical  manuals,  have  characteristics  which  are  closely 
related  to  the  type  of  equipment  or  system  which  is  to  be  repre¬ 
sented.  As  a  result,  mechanical  system  function  diagrams  will  be 
different  from  electronic  system  diagrams.  In  addition,  the  range 
of  complexity  and  size  may  vary  from  a  diagram  containing  only  a 


few  simple  entries  to  one  that  (if  paper-based)  may  contain 
thousands  of  entries  with  as  many  interrelationships,  and  extend 
over  many  foldout  pages.  In  the  latter  case  it  becomes  necessary 
to  provide  referents  when  a  line  of  flow  must  be  interrupted,  on 
both  the  "from"  page  and  the  "to"  page,  so  that  the  user  can  make 
the  connection.  Although  unwieldy,  a  user  can  refer  to  multiple 
pages  of  function  diagrams  in  paper-based  systems  when  items  of 
interest  are  on  separate  pages.  In  a  computer-based  system  with 
a  single  screen,  however,  it  will  be  difficult  to  jump  back  and 
forth  between  two  function  diagram  frames  that  are  supposed  to  be 
continuous  without  losing  one's  place.  Screen  size  increases  the 
burden  since  only  a  small  portion  of  a  large  and  complex  diagram 
can  be  displayed  legibly  at  any  one  moment. 

An  a Jl j L ional  consideration  for  formatting  of  function  diagrams 
t.  the  use  to  which  they  may  be  put.  The  same  diagram  may  be 
examined  to  try  to  understand  the  system  interrelationships,  to 
try  to  trace  a  particular  path,  or  to  try  to  identify  interfaces 
with  a  particular  point.  It  may  be  used  for  testing,  for 
troubleshooting,  or  simply  for  general  reference.  VAMIS  function 
diagrams  should  be  able  to  support  all  such  uses. 

The  development  of  these  function  diagram  format  concepts  and 
guidelines  was  based  on  the  following  premises: 

•  The  user  should  have  maximum  flexibility  in  moving  between 
one  portion  of  the  function  diagram  pool  and  any  other 
related  portion. 

•  Extra  care  should  be  taken  to  prevent  the  user  from  getting 
lost . 

•  The  computer  system  should  have  the  task  of  making  inter¬ 
connections  between  "interrupted"  points  in  the  same  flow. 


•  The  diagram  should  be  legible  and  useful  at  the  time  of 

initial  presentation  on  the  screen.  Since  function  diagrams 
are  part  of  pool  information.  Level  3  legibility  criteria 
apply. 

6.3.3  Approach 

6. 3. 3.1  Function  Diagram  Access  Paths.  Methods  defined  to 
enable  users  to  access  particular  function  diagrams  of  interest 
are  depicted  in  Figure  6-22.  This  methodology  has  much  in 
common  with  the  logic  used  for  accessing  IPBs  and  is  based  upon 
the  anticipated  use  of  both  the  standard  mode  and  the  user 
request  mode  of  operation.  Although  not  specifically  shown  in 
the  figure,  the  method  assumes  that  the  function  diagram  portion 
of  pool,  like  the  IPB  portion,  will  be  treated  as  a  discrete 
portion  of  the  data  base,  allowing  the  user  to  move  about  within 
it  with  more  flexibility  than  in  other  portions  of  pool.  Once 
the  user  has  accessed  the  function  diagram  portion  of  pool,  all 
control  unit  keys  are  operable  in  the  same  manner  as  if  the  user 
was  in  the  text  portion.  The  exception  is  the  RETURN  function, 
which  normally  always  takes  the  user  back  to  the  last  frame  of 
procedural  text,  or  other  non-pool  data,  which  was  displayed 
prior  to  accessing  the  function  diagrams.  In  certain  circum¬ 
stances,  to  be  explained  later,  use  of  the  RETURN  key  in  the 
function  diagram  pool  will  take  the  user  back  to  a  higher-level 
function  diagram.  In  the  standard  mode,  the  number  of  steps 
required  to  reach  a  usable  function  diagram  will  depend  on  the 
specificity  of  the  reference  in  the  options  list  (or  other  in- 
text  reference)  and  the  complexity  of  the  diagram.  In  the  ideal 
case,  the  technician  may  be  able  to  go  directly  from  an  options 
list  to  a  usable  simple  function  diagram.  In  the  worst  case, 
the  technician  may  have  to  go  through  a  series  of  lists  and 
higher  level  diagrams  to  obtain  the  specific  usable  diagram 
wanted. 
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The  same  access  constraints  apply  to  the  user  request  mode,  with 
the  added  constraint  that  the  shortest  access  path  is  heavily 
dependent  on  what  the  technician  already  knows  about  what  is 
needed,  and  how  many  other  function  diagrams  satisfy  the  same 
function  diagram  identification  criteria.  For  example,  if  a 
technician  in  the  user  request  mode  calls  for  a  diagram  with  a 
MIDAS  code  input,  there  may  be  a  sizable  number  of  schematics 
(or  wiring  diagrams)  with  the  same  MIDAS  code,  making  it 
impossible  for  the  system  to  go  directly  to  the  specific  diagram 
needed  by  the  technician.  In  such  cases  the  system  goes  to  a 
menu  frame  which  lists  all  of  the  schematics  available  with  the 
MIDAS  code  which  was  input.  The  technician  would  then  select 
the  specific  diagram  needed,  in  the  standard  mode. 

Figure  6-23  illustrates  an  example  of  a  function  diagrams  list 
that  might  be  accessed  in  the  standard  mode.  Similar  menus 
should  be  provided  for  accessing  via  the  user  request  mode,  as 
applicable.  If  lengthy  lists  will  require  more  than  one  frame, 
they  should  be  split  according  to  some  logical  method  of 
organization.  Note  that,  within  groups,  unless  there  is  a 
logical  order  of  presentation,  listings  should  be  in  alphabetic 
or  numeric  sequence  to  assist  in  scanning  the  list.  If  the  TO 
data  base  will  also  contain  wiring  diagrams  (WD) ,  a  short  list 
could  be  included  as  a  group  here,  or  a  selectable  cross- 
reference  to  the  wiring  diagrams  list  could  be  shown. 

6. 3. 3. 2  Complexity  Factors.  As  was  mentioned  above  and  illus¬ 
trated  in  Figure  6-22,  the  actual  path  to  be  taken  to  obtain  a 
usable  function  diagram  will  depend  heavily  on  the  size  and 
complexity  of  the  diagram.  The  access  logic  and  format  samples 
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Figure  6-23.  Example  of  VAMXS  function  diagrams  list. 


discussed  later  in  this  section  are  based  on  definition  of  three 
types  of  diagrams,  where  size  and  complexity  are  the  differ¬ 
entiating  factors.  The  three  types  are: 

a.  Simple  Diagram  (Type  1) .  The  diagram  is  sufficiently  simple 
that  all  elements  of  the  diagram,  both  text  and  graphics, 
will  satisfy  the  Level  3  legibility  criteria  at  the  time  of 
initial  display  of  the  complete  diagram. 


V  in  .  _ 


b.  Medium  Complexity  Diagram  (Type  2) .  The  diagram  can  be 
presented  complete  in  one  frame  with  all  graphics  and 
identification  labels  for  major  elements  satisfying  the 
Level  3  legibility  criteria.  Graphic  and  text  details, 
however,  will  not  be  sufficiently  legible  without  increasing 
the  size  of  the  diagram  through  use  of  the  zoom  feature. 

c.  High  Complexity  Diagram  (Type  3) .  The  diagram  is  either  so 
large  or  so  complex  that  none  of  it  would  meet  the  legibility 
criteria  if  it  was  presented  complete  in  one  frame. 

As  is  shown  in  Figure  6-22,  the  simple  case  (Type  1)  diagram 
can  be  accessed  directly  when  the  specific  diagram  selection  is 
made  and  is  fully  usable.  The  Type  2  diagram  is  equally  available 
but  will  require  manipulation  of  SCREEN  controls  before  it  is 
fully  usable.  The  Type  3  diagram  will  require  an  intervening 
selection  step  before  a  usable  diagram  can  be  obtained.  The 
format-related  characteristics  of  each  diagram  type  are  discussed 
and  illustrated  later  in  this  section. 

6.3.3. 3  Location  Feedback.  One  of  the  anticipated  problems  of 
technicians  entering  the  function  diagram  pool  is  that  of  getting 
lost,  or  losing  the  point  of  reference  within  the  diagram.  This 
will  be  particularly  risky  if  diagrams  are  increased  in  size  with 
the  zoom  feature  and/or  moved  with  the  pan  feature  so  that  the 
complete  diagram  is  not  visible.  To  counter  this  anticipated 
problem,  the  following  guidance  should  be  observed: 

a.  The  header  portion  of  the  frame,  as  in  other  portions  of  the 
data  base,  should  contain  all  appropriate  identifying  infor¬ 
mation  and  should  remain  in  the  field  of  view  at  all  times. 

It  should  not  be  considered  as  part  of  the  illustration  so 
that  it  becomes  subject  to  being  panned  or  zoomed  out  of  the 
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viewable  area.  With  illustration  space  severely  limited, 
there  will  be  a  temptation  to  make  use  of  this  display  area 
for  the  diagram  itself.  However,  many  diagrams  are  so 
similar  in  content  that,  without  identifying  information, 
they  could  easily  be  confused  with  each  other.  For  example, 
if  magnified  portions  of  two  similar  diagrams  were  placed  in 
memory  without  the  identifying  information,  when  SHOW  1  and 
SHOW  2  were  pressed  it  would  be  extremely  difficult  to 
recognize  which  diagram  was  which. 

b.  Al]  diagrams  should  contain  location  coordinates  to  assist 
the  technician  in  determining  location  within  the  diagram. 

The  top  margin  and  the  left  margin  of  the  diagram  are 
recommended  for  this  purpose.  A  slave  windowing  approach 
should  be  used  so  that,  if  the  diagram  is  panned  or  zoomed, 
the  portions  of  the  location  coordinates  that  are  associated 
with  the  visible  portion  of  the  diagram  contents  will  remain 
in  the  viewable  area  in  the  correct  relationship.  This 
approach  is  described  and  illustrated  in  some  of  the  examples 
which  follow. 

C.3.3.4  Use  of  Prompts  and  Advisories.  The  guidance  which 
applies  to  other  types  of  VAMIS  formats  is  equally  applicable  to 
the  data  in  the  function  diagrams  pool.  In  addition,  the  data 
preparer  should  anticipate  the  desirability  of  using  some  of  the 
routine  system  functions,  such  as  memory  and  screen  control,  and 
provide  prompts  to  that  effect  when  prompt  space  is  available. 

6.3.4  Introductory  Materials 

As  a  discrete  portion  of  the  computer-based  TO,  the  function 
diagrams  pool  has  its  own  set  of  front  matter  and  introductory 
materials.  This  could  include  a  sectional  title  frame,  as  was 
used  in  the  IPB  (Figure  6-2),  a  table  of  contents  and  list  of 


and  unexpected  characteristics  of  the  diagrams  should  be 
explained  for  the  user.  The  use  of  key  codes  within  the  text 
enables  the  user  to  efficiently  access  a  particular  frame  as  an 
example  to  clarify  the  text  discussions.  The  description  makes 
no  m.-ntlon  of  the-  placement  or  use  of  key  codes  or  other  standard 
VA.MI5  attributes  since  they  are  not  unique  to  the  function 
diagrams.  Mention  is  made,  however,  of  the  two  different  types 
of  presentation  of  highly  complex  schematics  since  this  is  not 
.routinely  available  in  the  VAMIS  approach  to  technical  information 
presentation . 

b.3.5  Simple  Function  Diagrams  (Type  1) 

lope  1  function  diagrams  are  those  which  can  be  structured  and 
prepared  to  dc  completely  visible  and  meet  all  Level  3  legibility 
or : tenia  upon  initial  screen  display.  An  example  of  a  Type  1 
diagram  is  depicted  in  Figure  6-25.  The  user  can,  if  desired, 
further  increase  magnification  with  the  zoom  feature  and  move  the 
diagram  around  on  the  screen  for  use  at  a  more  distant  work 
location.  In  addition,  the  example  shows  how  directly  related 
d:  jejrams  are  noted  and  key-coded  for  direct  access  rather  than 
requiring  use  of  an  options  list  or  other  menu  approach. 

G . 3.6  Medium  Complexity  Function  Diagrams  (Type  2) 

Typo  2  function  diagrams  are  those  which  are  too  lengthy  or 
coir;  icx  to  qualify  as  Type  1  diagrams,  but  which  can  be 
structured  and  prepared  so  that  the  total  diagram  is  visible  and 
the  major  elements  meet  Level  3  legibility  criteria  at  the  time 
of  initial  presentation.  An  example  of  a  Type  2  diagram  at  the 
time  of  initial  presentation  is  shown  in  Figure  6-26.  Major 
function  titles  and  locator  legends  are  sized  for  initial 
legibility,  and  the  technician  is  prompted  to  use  the  screen 
controls  to  further  increase-  legibility  of  the  details. 


f.  -  3  7 


Figure  6-25.  Example  of  VAMIS  function  diagram.  Type  1 
(simple  schematic) . 

Figure  6-27  shows  an  example  of  use  of  the  zoom  and  pan  control 
functions  to  increase  legibility  of  the  diagram.  Note  that 
although  portions  of  the  diagram  have  disappeared  from  the 
illustration  "window"  as  a  result  of  such  control  actions,  the 
portion  of  the  locator  grid  which  is  associated  with  the 
remaining  portion  of  the  diagram  stays  in  the  viewable  area. 
Independent  windowing  allows  the  grid  to  change  size  along  with 
the  diagram  and  keeps  it  aligned,  but  prevents  the  useful 
portion  from  going  off-screen.  Note  also  that  this  illustration 
contains  some  lower-case  characters  (a,  b,  and  c  on  the  Brake 
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Figure  6-26.  Example  of  VAMIS  function  diagram.  Type  2 
(moderately  complex  schematic,  initial 
presentation)  . 

Control  Unit  board) .  Since  this  represents  the  actual  labeling 
on  the  board,  and  the  diagram  can  be  zoomed-up  for  legibility, 
the  character  style  and  Level  3  character  size  criteria  can  be 
deviated  from. 
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user  screen  control  actions) . 


A  different  approach  is  presented  in  Figure  6-28.  In  this 
example,  the  block  diagram  serves  the  dual  purpose  of  providing 
a  functional  overview  of  the  system  (its  primary  role)  ,  as  well 
as  a  means  of  selecting  an  individual  functional  diaqram.  In 
its  primary  role  it  is  a  Type  2  diagram.  In  its  other  role  it 
serves  as  an  orientation  diagram  (discussed  in  subparagraph  6. 7. 3.1 
below),  so  that  if  the  user  needs  more  functional  detail  than  is 
available  on  the  block  diagram,  the  individual  functional  dia  ;i.im 
can  be  selected. 
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Figure  6-28.  Example  of  VAMIS  function  diagram.  Type  2 
(block  diagram) . 


6.3.7  High  Complexity  Function  Diagrams  (Type  3) 

Type  3  function  diagrams  are  those  that  are  too  lengthy  or  too 
complex  to  be  prepared  as  either  Type  1  or  Type  2  diagrams. 
Type  3  function  diagrams  will  require  special  efforts  by  the 
data  preparer  and  special  actions  by  the  user  to  obtain  usable 
schematic  and  wiring  diagrams.  Type  3  function  diagrams  for 
presentation  on  VAMIS  will  involve  three  diagram  subtypes: 
orientation  diagrams,  subfunction  diagrams,  and  main  diagrams. 
Each  subtype  and  its  interrelationships  are  discussed  below. 


6. 3. 7.1  Orientation  Diagrams.  An  orientation  diagram  is 
displayed  as  the  initial  presentation  of  a  complex  and  lengthy 
schematic  (or  other  function)  diagram  which  cannot  be  handled  as 
in  the  simple  or  medium  complexity  cases.  Its  purpose  is  to 
allow  the  user  to  become  familiar  with  the  contents  of  the 
schematic,  and  to  select  both  the  type  of  presentation  and  the 
starting  point  desired.  Figure  6-29  shows  an  example  of  an 
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orientation  diagram  based  on  a  hard  copy  schematic  consisting  of 
two  foldout  sheets,  which  if  connected  would  measure  approximately 
11  by  44  inches.  All  detail  is  eliminated,  but  all  functional 
entities  are  represented  in  the  approximate  same  relationship  as 
in  the  original  diagram.  The  function  blocks  are  graphically 
coded  (by  dashes)  the  same  as  the  original  diagram  to  indicate 
the  level  of  the  function.  Number  and  letter  codes  are  provided 
within  the  blocks  as  a  means  of  selecting  the  detailed  subfunction 
diagram  of  interest  (see  subparagraph  6. 3. 7. 2)  or  the  equivalent 
detailed  section  of  the  main  diagram  (see  subparagraph  6. 3. 7. 3). 
Since  the  orientation  diagram  is  structurally  complete  and 
legible  at  initial  display,  it  is  technically  a  Type  1  diagram. 
However,  since  it  has  insufficient  functional  detail  to  be  used 
as  a  function  diagram,  and  is  a  necessary  step  in  the  process  to 
obtain  that  detail,  it  is  classified  as  a  Type  3  diagram. 

Pi  cure  6-30  illustrates  an  alternate  method  of  presenting  an 
orientation  diagram.  This  approach  may  be  useful  when  the 
physical  relationships  of  the  equipment  or  components  comprising 
the  diagram  are  important  to  understanding,  and  the  size  of  the 
diagram  does  not  preclude  single-frame  presentation  even  if  the 
complexity  is  too  great.  In  this  case,  all  textual  detail  and 
some-  graphic  detail  has  been  eliminated  and  key  code  callouts 
were  used  to  identify  the  significant  elements  of  the  diagram. 

The  user  can  input  a  key  code  to  obtain  a  specific  subfunction 
just  as  in  the  preceding  example.  Alternately,  the  user  can 
specify  a  particular  coordinate  location  to  obtain  a  legible 
presentation  of  the  equivalent  portion  of  the  main  diagram,  with 
all  detail  included.  Input  of  coordinate  locations  for  this 
purpose  was  not  used  in  the  first  orientation  diagram  example 
since  it  did  not  have  the  same  physical  layout  as  the  main 
diagram  that  it  represented. 
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Figure  6-30.  Example  of  VAMIS  function  diagram,  Type  3 

(orientation  diagram  for  complex  schematics; 
Example  2) . 


6. 3. 7. 2  Subfunction  Diagrams.  This  subtype  of  the  Type  3 
function  diagram  is  intended  to  provide  one  means  for  technicians 
to  obtain  the  functional  detail  needed  for  task  performance. 

These  diagrams  are  obtained  by  selecting  a  numeric  code  on  the 
orientation  diagram,  and  consist  of  two  closely  related  parts: 
the  subfunction  and  the  subfunction  interfaces.  The  basic 
subfunction  diagram  shows  the  detail  of  a  specific  functional 
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entity.  The  subfunction  interface  diagram  shows  the  detail 
between  any  two  subfunctions  that  are  functionally  related. 

Figure  6-33  shows  an  example  of  a  basic  subfunction  diagram,  a 
discrete  portion  of  a  complex  functional  diagram.  This  is  the 
display  that  would  result  if  the  user  selected  key  code  [4]  in 
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the  orientation  diagram  in  Figure  6-29.  The  diagram  shows  all 
of  the  block  400,  Relay  Chassis  functions,  and  identifies  the 
functional  interfaces  that  are  relevant  to  the  Clock/Resolver 
function.  The  user  can  show  a  diagram  of  any  particular  inter¬ 
face  or  go  to  a  related  functional  diagram  by  inputting  the 
appropriate  key  code.  Note  that  the  Relay  Chassis  subfunctions 
on  the  main  Clock/Resolver  function  diagram  are  split  into  two 
parts,  in  two  separate  parts  of  the  diagram,  as  shown  in  the 
orientation  diagram  (Figure  6-29) . 


An  example  of  a  subfunction  interface  diagram  (SID)  is  shown  in 
Figure  6-32,  depicting  the  functional  interface (s)  between  two 
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Figure  6-32.  Example  of  VAMIS  function  diagram,  Type  3 
(high  complexity;  subfunction  interface 
diagram) . 
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Clock/Resolver  subfunctions.  This  is  the  SID  that  would  result 
from  selection  of  key  codes  [8]  or  [4]  in  the  example  in 
Figure  6-31.  A  SID  permits  the  user  to  identify  the  interfaces 
between  any  two  subfunctions  of  the  same  function,  including  any 
relevant  character i sties  (e.g.,  test  points),  without  the 
imposition  of  irrelevant  detail.  In  addition,  the  SID  allows 
the  user  to  trace  from  one  svibf unction  to  another,  through  a 
complete,  complex  function  diagram  if  necessary.  Selection  of 
key  codes  [A]  or  [B]  on  this  SID  example  would  obtain  the  sub¬ 
function  diagrams  illustrated  in  Figures  6-31  and  6-33, 
respectively . 
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Figure  6-33.  Example  of  VAMIS  function  diagram,  Type  3 
(subfunction  diagram  for  high  complexity 
schematic.  Example  2). 
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Figure  6-33  shows  another  example  of  a  subfunction  diagram.  This 
is  the  display  that  would  result  if  the  user  selected  key  code 
[11]  in  the  orientation  diagram  in  Figure  6-29,  or  key  code  [B] 
in  the  subfunction  interface  diagram  in  Figure  6-32.  The  diagram 
shows  all  of  the  block  1100,  Regulator  functions  and  functional 
interfaces  that  are  relevant  to  the  Clock/Resolver  function. 

The  user  can  show  a  diagram  of  any  particular  interface,  or  go 
to  a  related  functional  diagram,  by  inputting  the  appropriate 
key  code.  Note  that  selection  of  key  code  [B]  which  follows  the 
reference  to  the  Power  Distribution  function  would  obtain  the 
Type  1  diagram  illustrated  in  Figure  6-25. 

6. 3. 7. 3  Main  Diagrams.  This  subtype  of  the  Type  3  function 
diagram  comprises  enlarged  sections  of  the  actual  function  diagram 
The  example  in  Figure  6-34  illustrates  the  display  of  a  portion  of 
a  complex  function  diagram  that  might  result  from  selection  of 
letter  code  [H]  from  the  orientation  diagram  in  Figure  6-29. 

This  display  is  equivalent  to  the  subfunction  diagram  shown  in 
Figure  6-33,  but  path  tracing  must  be  accomplished  through  use  of 
the  pan  keys  rather  than  by  key  code  selection.  Assuming  that 
such  a  schematic  has  been  drawn  to  meet  the  applicable  specifi¬ 
cation  requirements,  additional  format-related  requirements  for 
video  display  are  minimal.  They  include  legibility  of  main 
labels  at  the  time  of  initial  presentation,  connection  of  multi¬ 
sheet  schematics  into  a  continuous  diagram,  and  assembly  of  any 
notes  for  on-demand  presentation. 

The  computer  programming  will  have  to  edge-match  the  appropriate 
sections  of  the  diagram  both  for  initial  presentation  and  as  the 
user  pans  through  it.  If  each  section  is  prepared  to  fill  a  full 
frame  at  initial  presentation,  portions  of  up  to  4  adjacent 
sections  could  be  required  for  display  at  any  given  moment. 


in  the  corner  of  the  frame  when  requested  by  the  user.  V!hile 
the  note  window  is  being  displayed,  the  prompt  would  change  to: 


D 

D 


FOR  EXPLANATION  OF  DIAGRAM  NOTES: 
[ENTER] . 


TO  ERASE  NOTE  WINDOW: 
[ENTER] . 


INPUT  NOTE  NUMBER  [  ] 

INPUT  SAME  NOTE  NUMBER  [  ] ; 


This  will  permit  the  user  to  review  any  referenced  note  in  the 
context  of  the  diagram  contents  to  which  it  applies,  and  then 
clear  it  when  it  is  no  longer  needed. 


Figure  6-35  presents  a  second  example  of  the  main  diagram 
approach  to  Type  3  function  diagrams.  This  example  illustrates 
the  display  of  a  portion  of  a  complex  function  diagram  that 
might  result  from  selection  of  coordinates  [CIO]  from  the 
orientation  diagram  in  Figure  6-30.  Note  that  the  location 
coordinate  scale  visible  in  Figure  6-35  bears  the  same 
relationship  to  diagram  contents  as  that  in  Figure  6-30.  As  in 
the  first  main  diagram  example,  path  tracing,  if  desired,  can  be 
accomplished  through  use  of  the  screen  control  pan  keys.  In 
the  example  shown  here,  character  size  and  style  of  the 
component  labels  do  not  meet  the  specified  legibility  criteria. 
In  addition,  some  of  the  graphic  coding  used  in  the  original 
paper  copy  may  not  be  adequate  for  CRT  presentation,  e.g.,  the 
small  "dot"  patterns  used  for  pneumatic  pressure  and  retraction 
pressure,  because  of  insufficient  resolution.  The  legend  for 
the  graphic  codes  is  placed  in  a  window  in  one  corner  of  the 
frame.  It  does  not  move  in  response  to  panning  of  the  schematic 
If  the  diagram  contained  notes,  they  would  be  presented  and 
erased  as  described  for  Example  1. 
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Figure  6-35.  Example  of  VAMIS  function  diagram.  Type  3 
(high  complexity;  section  of  main  diagram; 
Example  2) . 


6.4  OTHER  PROCEDURAL  SUPPORT  POOL  DATA 


6  .  4  .  ]  Introduction 

Procedural  support  pool  data  encompass  the  types  of  data  which  a 
technician  may  want  to  have  available  either  as  a  supplement  to 
or,  i n  the  case  of  experienced  technicians,  as  a  substitute  for 
th-  f  :  <•  ceu  urdl  track  data.  Two  major  types  of  procedural 
s  ::  : or t  ;ccl  data  are  Illustrated  Parts  Breakdowns  and  function 


diagrams,  discussed  in  Subsections  6.2  and  6.3,  respectively. 

This  section  discusses  some  of  the  remaining  types  of  procedural 
support  pool  data  which  should  be  anticipated  as  necessary  in  a 
VAMIS-type  system.  These  types  include: 

•  Access  and  locator  diagrams 

•  Test  setup  instructions 

•  Test  specifications. 

Procedural  support  data  can  be  accessed  by  the  user  in  either 
the  standard  mode  or  the  user  request  mode  of  operation.  In  the 
standard  mode,  most  efficient  access  is  obtained  by  selecting 
the  data  wanted  from  the  options  list  for  the  reference  procedures 
frame.  Alternately,  the  user  can  obtain  the  data  via  tables  of 
contents  (TOCs) . 

The  guidance  in  Section  3.0  applies  to  procedural  support  data 
as  well  as  other  types  of  VAMIS  data.  In  addition,  data  which 
are  required  for  performance  of  maintenance  should  be  included 
in  the  procedural  instructions  to  the  extent  applicable  so  that 
the  technician  does  not  have  to  request  the  data.  Applicability 
will  often  be  determined  by  the  track,  or  level  of  detail,  of 
the  procedures  involved.  Thus,  a  specific  locator  diagram  for  a 
part  may  be  included  in  the  illustration  for  a  Track  3  procedure, 
but  omitted  in  the  other  two  tracks.  Inclusion  of  specific 
support  data  in  procedures  does  not  eliminate  the  need  to 
provide  the  data  in  pool,  although  the  same  basic  data  may  be 
used  in  both  places. 

Since  it  is  part  of  pool,  procedural  support  data  are  normally 
prepared  to  Level  3  character  size  criteria.  However,  since  by- 
nature  they  may  be  used  to  support  the  performance  of  mainte¬ 
nance,  the  data  should  be  legible  when  viewed  from  the  work 


location.  This  can  be  accomplished  by  having  all  procedural 
support  information  on  the  frame  (except  the  heading)  subject  to 
the  zoom  and  pan  controls,  as  is  assumed  in  the  examples  in  this 
section,  or  by  preparing  the  information  to  Level  5  criteria. 

G  .  4 . 2  Access  and  Locator  Diagrams 

Access  and  locator  diag tarns  (ALDs)  are  used  to  help  technicians 
find  a  particular  part  or  assembly  and,  in  some  instances,  to 
determine  what  other  parts  or  assemblies  interconnect  with  it, 
hide  it,  or  are  hidden  by  it.  Although  not  as  detailed  as 
breakdown  illustrations,  access  and  locator  diagrams  are  also 
useful  in  determining  the  sequence  of  removal/installation  or 
disassembly/assembly  if  the  detail  is  adequate. 

ALDs  should  be  prepared  for  each  major  assembly,  as  a  minimum, 
and  at  a  lower  level  if  needed.  To  the  extent  feasible  without 
causing  too  much  congestion  on  the  ALD  frame,  a  particular  ALD 
should  be  complete  in  the  fewest  number  of  frames.  When  more 
than  one  frame  is  needed,  a  messane  should  be  included  in  each 
frame  noting  the  availability  of  additional  data.  Figures  6-36 
and  G-37  illustrate  examples  of  a  two-frame  ALD.  When  an  ALD  is 
accessed  in  the  standard  mode,  the  first  frame  of  a  multi-frame 
scries  will  be  displayed  first.  The  user  can  move  between  the 
frames  using  the  [FORWARD]  and  [REVERSE]  keys  on  the  control 
unit.  Character  size  of  legends  in  the  illustration  are  not 
critical  since  the  entire  illustration  can  be  zoomed  up, 
panned,  etc.  for  increased  legibility  of  detail.  Callouts  are 
not  normally  used  in  ALDs  since  there  is  no  text  involved  and 
using  callouts  requires  additional  visual  search.  Callouts  may 
be  used  if  they  would  reduce  overall  diagram  complexity,  but  the 
referenced  legends  should  always  appear  on  the  same  frame  as  the 
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Figure  6-36.  Example  of  VAMIS  access  and  locator  diagram 
(ALD)  (first  frame  of  two-frame  ALD) . 


illustrated  part,  as  shown  in  Figure  6-38.  When  ALDs  use  an 
inset  for  cross-referencing  component  names  to  the  illustrated 
part,  the  inset  must  meet  the  character  size  criteria  since  it 
should  not  be  subject  to  the  panning  and  zoom  controls. 
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instructions  for  procedural  support  pool  data  should  be  prepared 
at  the  level  of  detail  needed  by  users  who  do  not  have  them 
integrated  with  their  maintenance  procedures.  For  example,  if 
Track  3  procedures  include  test  setup  instructions,  but  Track  2 
and  Track  1  procedures  do  not,  then  test  setup  instructions  in 
pool  should  be  at  the  Track  2  level  of  detail  so  they  are  usable 
by  both  Track  2  and  1  technicians.  In  such  a  case,  the  options 
lists  for  Track  2  and  Track  1  would  include  the  test  setup 
instruction  entry,  but  the  Track  3  options  list  would  not. 
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In  all  cases,  the  input  conditions  for  a  particular  checkout  or 
fault  isolation  procedure  should  include  the  need,  where  appli¬ 
cable,  to  set  up  the  test  equipment  according  to  the  appropriate 
instructions  unless  the  instruction  is  fully  integrated  in  the 
maintenance  procedure.  When  there  is  doubt  regarding  proper 
placement  of  test  setup  instructions,  preference  is  to  include 
test  setup  instructions  with  the  maintenance  track  procedures. 

If  the  test  setup  is  unique  to  a  particular  test,  it  should  be 
integrated  with  the  test  procedures.  If  the  test  setup  is 
common  to  a  number  of  different  tests,  it  should  be  prepared  as 
a  separate  task  procedure  covering  all  common  setup  requirements, 
with  unique  setup  requirements  in  the  individual  test  procedures 
(c.g.,  switch  settings).  Operating  instructions  for  standard 
and  special  test  equipment  are  generally  not  included  in  test 
setup  instructions.  Where  applicable,  these  should  be  included 
in  the  pool  reference  data  or,  in  some  instances,  in  separate 
TOs  which  can  be  accessed  as  needed. 

6.4.4  Test  Specifications 

Test  specifications  are  generally  of  two  types:  (1)  test  specifi¬ 
cation  tables  that  list  quantitative  values  and  tolerances,  if 
applicable,  which  are  acceptable  for  each  listed  test  condition, 
and  (2)  diagrams  such  as  waveform  guides  which  illustrate  how 
the  test  equipment  (or  the  tested  equipment)  should  respond  to 
the  test  condition.  As  with  test  setup  instructions,  test 
specifications  should  be  included  in  track  procedures  according 
to  the  needs  of  the  user  of  that  track  data.  Ordinarily,  all 
three  tracks  of  procedural  data  will  include  the  appropriate 
test  specifications,  since  even  the  most  experienced  technician 
should  not  be  expected  to  accurately  remember  more  than  a  few 
test  specifications.  In  addition,  there  may  be  a  need  to 
provide  a  consolidated  listing  of  test  specifications  for  use  by 
technicians  who  are  troubleshooting  from  schematic  diagrams  or 


out  a  problem  not  covered  by  procedures.  Such 
listing  might  include  normal  values  for  a  seri 
ts,  for  example,  such  as  is  illustrated  in  Figu 
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SECTION  7.0 

GUIDELINES  FOR  MAINTENANCE  PROCEDURE  FORMATS 


7.1  GENERAL  CONSIDERATIONS 

Maintenance  procedures  in  VAMIS  are  prepared  at  three  levels 
of  detail,  or  "tracks."  By  definition,  maintenance  procedures 
will  include  all  procedural  information  that  does  not  involve 
troubleshooting ,  checkout,  fault-isolation,  and  test.  The 
following  types  of  maintenance  activities  are  encompassed  by 
this  definition: 

•  Inspection 

•  Cleaning 

•  Disassembly  or  removal 

•  Assembly  or  installation 

•  Lubrication 

•  Alignment,  adjustment,  and  calibration 

•  Pre-operational  check 

•  Popair. 


Each  set  of  maintenance  procedures  will  include  the  input 
conditions  for  performing  the  selected  tasks,  the  procedures 
to  be  accomplished,  and  provisions  for  follow-on  activities 
which  may  be  necessary.  Variations  in  level  of  detail  for 
each  of  the  three  tracks  may  apply  to  all,  or  only  part,  of 
the  data.  (See  subparagraph  1.3.1e  for  criteria  which  define 
each  track.)  Baseline  requirements  for  maintenance  procedure 
formats  (discussed  and  illustrated  in  Subsection  2.2)  start  with 
the  Job  Guide  format,  from  specifications  MIL-M-38800A  and  MIL-M 
83495,  and  are  dependent  on  the  dual-level,  or  "hybrid,"  format 
specified  in  MI L-M- 38800A.  Performance  of  a  task  analysis 
according  to  the  modified  methodology  (Ref.  7)  defined  during 
this  project  is  recommended.  That  methodology  is  based  on 
tailoring  the  maintenance  task  identification  and  analysis 


methods  and  guidance  of  AFHRL-TR-79-50  (Ref.  5)  and  AFHRL 
TR-80-21  (Ref.  6)  for  greater  applicability  to  a  computer-based, 
three- track  presentation  system. 

All  procedural,  i.e.,  track,  data  are  prepared  to  meet  the 
Level  5  viewing  distance  requirements.  This  includes  both  text, 
illustrations,  and  prompts,  and  should  be  achieved  when  the  frame 
first  appears  on  the  display  screen.  The  frame  code  "JG"  is  used 
on  all  frames  of  non-troubleshooting  maintenance  procedures. 

Prior  to  preparation  of  VAMIS  maintenance  procedures,  consider¬ 
ation  should  be  given  to  the  scope  of  the  task  to  be  performed, 
especially  for  assembly /disassembly,  remove/install,  and  similar 
multipart  tasks.  Conventional  paper-based  TOs  frequently 
describe  (at  some  level  of  detail)  the  necessary  performance 
in  one  direction,  then  summarize  the  other  direction  with  a 
statement  such  as  "reassemble  in  the  reverse  order."  Most  job 
guide-type  procedures  will  actually  describe  the  steps  required 
for  both  directions,  but  still  generally  treat  the  two  parts  as 
a  continuous  task  (i.e.,  first  take  it  apart,  then  put  it  back 
together) .  In  many  cases  this  is  actually  what  happens,  but  in 
many  other  cases  the  two  parts  are  not  continuous.  For  example, 
a  unit  may  be  partially  disassembled  in  order  to  obtain  a  part 
which  is  sent  off  somewhere  for  testing.  It  may  be  some  period 
of  time  before  the  part  (or  a  replacement)  is  returned  and  the 
unit  is  reassembled,  and  a  different  technician  may  be  involved. 

A  computer-based  presentation  system  provides  an  opportunity 
for  scaling  the  data  to  the  task  scope  which  the  technician 
actually  needs,  and  using  the  system's  accessing  and  prompting 
capabilities  for  linking  the  various  needed  parts. 

As  will  be  seen  from  the  discussion  and  examples  beginning  in 
Subsection  7.2,  the  VAMIS  approach  is  a  compromise  between 
complete  splitting  of  such  multipart  tasks  and  the  assumption 
that  the  task  is  continuous. 


7.2  INPUT  CONDITIONS  FORMAT 


The  input  conditions  (IC)  format  is  intended  to  identify  the 
task  to  be  performed,  the  equipment  to  which  the  particular  task 
applies,  the  number  and  type(s)  of  personnel  needed,  and  any 
special  supplies  ana  tools  which  may  be  required.  Input  con¬ 
ditions  will  also  include  descrip_:on  of  any  equipment  conditions 
which  must  be  satisfied  prior  to  task  initiation,  and  a  summary 
of  the  procedure.  Depending  on  the  complexity  of  the  task,  the 
amount  of  such  information  to  be  provided,  and  the  applicable 
track,  input  conditions  may  be  presented  on  a  single  frame  or 
in  a  series  of  frames.  To  the  extent  feasible,  input  conditions 
should  be  organized  so  that  data  to  be  presented  to  all  three 
tracks  are  on  common  frames.  This  will  reduce  the  number  of 
individual,  track-specific  frames  in  the  data  base. 

An  example  of  a  first  frame  of  input  conditions,  applicable  to 
Tracks  1,  2,  and  3,  is  illustrated  in  Figure  7-1.  This  is  the 
type  of  frame  tha4  would  appear  following  task  selection  from  a 
procedures  TOC  (see  Figure  4-7) .  Since  it  is  the  first  of  a 
series  of  frames  on  a  topic,  a  second-level  title  is  used  in 
the  header  to  ensure  that  the  technician  is  informed  of  the 
procedure  selected.  Since  the  same  information  is  needed  by 
all  three  tracks  (even  though  an  experienced.  Track  1  technician 
may  know  most  or  all  of  it) ,  it  is  combined  on  a  common  frame 
with  a  frame  code  identification  of  type  6. 

This  IC  frame  identifies  the  overall  task,  serial  number  appli¬ 
cability,  personnel  required,  and  supplies  and  special  tools  or 
equipment  needed  for  task  performance.  To  some  extent  the 
applicable  serial  numbers  entry  may  be  redundant  information  if 
the  user  has  been  presented  with  and  made  a  selection  from  the 
model/ser les  selection  menu  as  the  procedures  were  accessed  (see 
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subparagraph  4. 3. 3.1).  As  applicable,  the  frame  shows  whether 
the  listed  data  apply  to  the  remove  phase  or  the  install  phase. 
This  will  permit  the  user,  for  example,  to  obtain  only  those 
supplies  needed  f<5r  the  phase  of  the  task  intended  to  be  per¬ 
formed.  The  supplies  and  tools  list  would  be  a  likely  candidate 
for  printing  out,  if  the  system  included  a  print  capability  (see 
Subsection  3.10),  and  may  need  a  prompt  to  that  effect.  If  the 
supplies  and  tools  list  will  require  more  space  than  is  available 
on  the  first  IC  frame,  start  the  list  on  a  new  frame  rather  than 
break  it  in  the  middle  of  the  list. 


*  TO  1C-141A-2-AA  73-10-00  6JG  03592C 

(  C-141A  ENGINE  FUEL  SYSTEM  MAINTENANCE 

*  TASK  4-3:  FUEL  PUMP  FILTER  ELEMENT  REMOVAL  £  INSTALLATION.  1 


#  TO  1C-141A-2-AA  73-10-00  6JG  03592C 

(  C-141A  ENGINE  FUEL  SYSTEM  MAINTENANCE 

#  TASK  4-3:  FUEL  PUMP  FILTER  ELEMENT  REMOVAL  £  INSTALLATION.  1 

#  INPUT  CONDITIONS:  REMOVE  INSTALL 

•  APPLICABLE  SERIAL  NUMBERS _ ALL 

t  •  PERSONNEL  REQUIRED .  1  2 

#  -  SPECIALIST  WILL  BE  REQUIRED  TO  MOTOR 


*  AFFECTED  ENGINE  UPON  REQUEST  DURING  FUEL 

#  SYSTEM  ACTIVATION  A  CHECKOUT. 


•  SUPPLIES: 

#  -  ONE  GALLON  PLASTIC  CONTAINER .  1 

#  -  PETROLATUM  GREASE.  VV-P-236 .  -  J 

#  -  0-RING  PACKING,  MS9021-1  35 .  -  J 

#  -  WIPING  CLOTH  OR  TO'IELS  (WIPES) .  y /  J 

•  SPECIAL  TOOLS  AND  TEST  EOUIPMENT : 

#  -  MAINTENANCE  STAND,  TYPE  B-4A  (ALT : B- 1 A )  1  1 


t  -  TORQUE  WRENCH.  500  I NCH- POUNDS ( C AL I BRATE 0 ) -  1 


D  INPUT  CONDITIONS  CONTINUED:  [FORWARD]. 


Figure  7-1.  Example  of  VAMIS  maintenance  task  input 
conditions  frame  (all  tracks) . 
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The  next  IC  frame  to  appear  in  response  to  following  the  frame 
prompt  should  be  the  equipment  conditions  to  be  satisfied  before 
initiating  maintenance.  Depending  on  the  nature  of  the  equipment 
conditions,  this  could  be  accomplished  on  another  common  IC 
frame  or  may  require  separate  frames  for  each  track.  Figure  7-2 
illustrates  such  a  frame  that  is  common  to  two  of  the  tracks 
(Track  2  and  3) . 
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Example  of  VAMIS  maintenance  task  input 
conditions  continuation  frame  (Tracks  2  and  3). 


In  this  example,  the  nature  of  the  condition  to  be  satisfied  is 
significant  enough  to  require  detailed  instructions  for  both  of 
these  tracks.  The  same  basic  information  is  displayed  to  the 
technician  in  Track  1,  but  in  much  less  detail,  as  shown  in 
Figure  7-3.  The  two  equipment  conditions  listed  on  this  Track  1 
frame  would  require  sequential  frames  for  Tracks  3  and  2.  Note 
that,  regardless  of  track  level,  the  technician  is  not  permitted 
to  access  the  next  frame  until  equipment  condition  verification 
status  has  been  registered  according  to  the  prompt.  A  "YES" 
input  will  access  the  next  frame  for  the  track.  A  "NO"  input 
might  automatically  access  a  detailed  verification  procedure 
for  Track  3  and  an  advisory  message  to  Tracks  2  and  1  that 
verification  must  be  accomplished  before  going  further. 

When  accomplishment  of  all  equipment  conditions  has  been 
verified,  the  last  IC  frame  is  accessed.  Again,  skill  level 
differences  may  require  different  "Summary  of  Procedure"  frames 
for  each  track,  and  at  least  two  different  frames  will  be 
necessary.  Comparison  of  the  examples  in  Figure  7-4  and  7-5 
shows  only  minor  differences  in  the  frame  content  of  the  Track  2 
and  3  common  frame  and  the  Track  1  frame,  respectively.  The 
principal  differences  are  the  inclusion  of  a  reminder  to  Tracks 
and  3  that  specific  procedures  should  be  accessed  and  followed. 
The  experienced  Track  1  technician,  on  the  other  hand,  will 
normally  have  enough  information  in  the  summary  to  provide  such 
guidance  as  may  be  needed.  If  more  detail  is  needed.  Track  2 
or  even  Track  3  procedures  can  be  obtained  via  the  options  list 
(see  Figure  4-9) . 


*  TO  1 C -  1 4  I  A- ?- AA  73-10-00 

*  4-3:  INPUT  CONDITIONS.  CONTINUED. 
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«  EQUIPMENT  CONDITIONS: 


WARNING 

THE  FOLLOWING  EQUIPMENT  CONDITIONS  MUST  BE  MET  BEFORE 
DOING  THE  TASK  YOU  HAVE  SELECTED. 


# 


* 


LEFT-HAND  AFT  COWL  DOOR  OPENED  PER  TASK  NUMBER  1-4? 
FUEL  FROM  TANKS  SHUT  OFF  AND  DEICER  FILTER  DRAINED  PER 
TASK  NUMBER  1-4? 


*  r*>ApE  BOTH  CONDITIONS  VERIFIED?  INPUT  [YES]  OR  [NO]  [  ]; 

P  [ENTER]. 


Figure  7-3.  Example  of  VAM1S  maintenance  task  input 
conditions  continuation  frame  (Track  1) 
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4- 3 :  INPUT  CONDITIONS,  CONTINUED 
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•  SUMMARY  OF  PROCEDURE: 

-  ENSURE  APPLICABLE  EQUIPMENT  IS  IN  THE  CORRECT  CONDITION 
FOR  MAINTENANCE. 

-  REMOVE  FILTER  ELEMENT  FROM  THE  FUEL  PUMP. 

-  DISASSEMBLE  FUEL  PUMP  FILTER  ELEMENT. 

-  INSPECT  AND  CLEAN  FUEL  PUMP  FILTER  ELEMENT. 

-  ASSEMBLE  FUEL  PUMP  FILTER  ELEMENT. 

-  INSTALL  FILTER  ELEMENT  IN  THE  FUEL  PUMP. 

-  ACTIVATE  AND  CHECKOUT  FUEL  SYSTEM. 

-  PERFORM  REQUIRED  FOLLOW-ON  MAINTENANCE. 

.•  THIS  PROCEDURE  SHOULD  BE  PERFORMED  USING  THE  SPECIFIC 
PROCEDURES  WHICH  FOLLOW. 


0  F OR  NEXT  FRAME:  [FORWARD]. 

♦  0FOR  INSTALLATION  PROCEDURES  ONLY:  [NEXT  SEQUENCE]. 


Figure  7-4.  Example  of  VAMIS  maintenance  task  input 

conditions  summary  frame  (Tracks  2  and  3) 
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TO  1C-141A-2-AA  73-1P-P0 

4-3:  INPUT  CONDITIONS.  CONTINUED 
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•  SUMMARY  OF  PROCEDURE: 

-  ENSURE  APPLICABLE  EQUIPMENT  IS  IN  THE  CORRECT  CONDITION 
FOR  MAINTENANCE. 

-  REMOVE  FILTER  ELEMENT  FROM  THE  FUEL  PUMP. 

-  DISASSEMBLE  FUEL  PUMP  FILTER  ELEMENT. 

-  INSPECT  AND  CLEAN  FUEL  PUMP  FILTER  ELEMENT. 

-  ASSEMBLE  FUEL  PUMP  FILTER  ELEMENT. 

-  INSTALL  FILTER  ELEMENT  IN  THE  FUEL  PUMP. 

-  ACTIVATE  AND  CHECKOUT  FUEL  SYSTEM. 

-  PERFORM  REQUIRED  FOLLOW-ON  MAINTENANCE. 


D  ^  YOU  NEED  MORE  INFORMATION:  [LIST  OPTIONS]. 


Figure  7-5.  Example  of  VAMIS  maintenance  task  input 
conditions  summary  frame  (Track  1) . 

7.3  TRACK  3  MAINTENANCE  PROCEDURES 

Maintenance  procedures  for  the  least  skilled  and  experienced 
technician  are  prepared  at  a  very  detailed,  step-by-step  level. 
Illustrations  of  the  subject  equipment  are  always  provided,  at 
the  same  level  of  detail,  fully  integrated  with  the  procedural 
text.  Figure  7-6  shows  an  example  of  a  typical  Track  3  mainte¬ 
nance  procedure  frame.  On  each  such  frame,  instructions  for 
accomplishing  one  subtask  are  presented  in  dual-level  format, - 


W "  . . 
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i.e.,  a  statement  of  what  the  subtask,  consists  of  and  indentured 
below  it,  the  step-by-step  instructions  for  accomplishment.  Eac 
component  or  part  mentioned  in  the  text  is  keyed  to  a  detailed 
illustration. 


#  TO  1C-141A-2-AA  73-10-00 

4-3:  REMOVE  FUEL  PUMP  FILTER  ELEMENT 


3JG  03487F 
A 


#  A. REMOVE  FILTER  ASSEMBLY  FROM  FUEL  PUMP: 

1.  POSITION  CONTAINER  BELOW  FILTER  *1*  TO  CATCH  DRAINAGE. 


WIPE  ANY  FUEL  SPILLAGE  FROM  ENGINE  WITH  CLOTH  OR  TOWELS. 


2.  CUT  SAFETY  WIRE  AND  REMOVE  2  BOLTS  *2*  AND  WASHERS. 

3.  WITHDRAW  FILTER  ASSEMBLY  *1*  FROM  CAVITY  IN  FUEL  PUMP 

*  3*  . 


•>  Jsl 

)»W  - 

\r  *2*  TYPICAL 


J  *2*  TYPICAL 
2  PLACES 


0  NEXT  FRAME:  [FORWARD]. 


l'icjurc  7-6.  Example  of  VAMIS  maintenance  procedure  frame 
(Track  3)  . 


E 


Any  applicable  warnings,  cautions,  or  notes  which  apply  to  the 
subtask  are  inserted  in  the  text  at  the  proper  location.  At 
this  level  of  detail,  many  subtasks  will  require  more  than  one 
frame  to  present  the  instruction.  When  this  occurs,  the  subtask 
title  is  repeated  on  each  successive  frame  and  the  step  numbers 
continue  in  sequence.  The  illustration  on  each  successive  frame 
will  also  change,  showing  only  the  parts  which  are  relevant  to 
the  step  descriptions  on  the  same  frame. 

Illustrations  should  be  as  simple  as  possible  while  still 
accurately  representing  the  equipment.  Line  drawings  are 
preferred  with  irrelevant  detail  eliminated.  Shading,  texture, 
and  similar  graphic  detail  should  not  be  included  unless  it  will 
help  the  technician  locate  and  identify  the  part  of  interest.  In 
many  cases,  as  in  the  Figure  7-6  example,  the  illustration  will 
be  a  combination  of  access  and  locator  diagram  (ALD)  and  parts 
breakdown  illustration.  When  the  procedure  gets  beyond  the  need 
for  the  ALD,  it  should  no  longer  appear  on  the  screen.  When 
directional  arrows  are  used,  they  should  always  be  consistent 
with  the  step  being  performed.  For  example,  when  the  subtask  is 
describing  installation  of  the  filter  assembly  in  the  fuel  pump, 
the  ALD  directional  arrows  should  be  reversed  from  that  shown  in 
Figure  7-6. 

It  should  also  be  noted  that  the  callouts  used  in  the  text  and 
illustration  are  coded  as  "non-selectable. "  This  will  normally 
be  the  case  in  procedures,  since  the  illustration  should  already 
be  as  complete  as  needed  for  the  track  level.  On  the  rare 
occasions  when  some  further  data  or  illustrations  associated  with 
the  part  are  to  be  provided  on  request,  the  callout  should  be 
coded  as  selectable  (e.g.,  [  ])  and  the  prompt  or  a  note  should 

inform  the  user  of  what  will  be  obtained  by  the  selection. 


Procedures  for  conduct  of  maintenance  by  the  technicians  at  the 
middle  level  of  skill  and  experience  will  eliminate  much,  but  pot 
all,  of  the  details  which  are  characteristic  of  Track  3  procedures. 
As  shown  in  the  example  in  Figure  7-7,  the  text  description  is 
generally  limited  to  one  or  more  subtask  statements  (the  upper 
level  of  the  Track  3  dual-level  instruction)  and  any  appropriate 
warnings,  cautions,  and  notes.  Illustrations  may  also  be  used  to 
supplement  the  text  and,  if  so,  should  include  the  use  of  callouts 
in  both  text  and  illustrations. 


P 


Figure  7-8  illustrates  a  second  example  of  a  Track  2  maintenance 
procedure,  the  frame  which  would  follow  Figure  7-7  in  our  Track  2 
scenario.  The  illustration  has  changed  substantially  to  keep  it 
consistent  with  the  subject  being  covered  by  the  text.  This 
example  also  points  up  the  flexibility  for  a  VAMIS-type  system  to 
access  the  appropriate  next  frame,  depending  on  what  the  techni¬ 
cian  needs  to  do  when  the  end  of  a  task  phase  (remove  and  inspect) 
has  been  reached.  If  the  filter  element  (or  a  replacement)  is  to 
be  installed,  installation  procedures  will  be  provided  without  a 
break  in  continuity  when  the  technician  answers  "YES."  If  the 
technician  answers  "NO,"  perhaps  because  a  new  filter  element  is 
needed  but  not  available,  the  system  will  provide  instructions 
for  securing  the  equipment  before  leaving  it,  if  any  are  needed. 
This  might  include  ensuring  that  the  cover  is  secure  and  that  a 
tag-out  flag  is  attached.  At  the  conclusion  of  the  procedure  or 
follow-on  maintenance  activity,  the  system  will  display  to  the 
technician  instructions  for  either  "logging  off"  or  for  accessing 
some  other  part  of  the  data  base. 
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#  TO  1C-141A-2-AA  73-10-00 

#  4-3:  REMOVE  FUEL  PUMP  FILTER  ELEMENT 

# 
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# 


A.  REMOVE  FILTER  ASSEMBLY  *1*  FROM  FUEL  PUMP  CAVITY  *2*. 


. ---  NOTE  . 

CATCH  DRAINAGE  «  WIPE  SPILLAGE  FROM  ENGINE 


>  B.  DISASSEMBLE  ELEMENT  *3*  FROM  COVER  *4*. 


.  CAUTION  1 1  . . 

COVER  FUEL  PUMP  OPENING  «2*  WITH  COVER  *4*. 

I  I  I  t  I  I  I  I  l  l  I  I  I  I  I  I  I  I  I  I  >•  l  I  I  I  I  «  I  I  I  I  I  «•  t  I  I  I  <  I  I  •  I  I  I  «  I  I  I  I  t  I  I  I  *  I  I  t  I 


O  REMOVE  AND  INSPECT  CONTINUED:  [FORWARD]. 


V. 


J 


V*  .-V 


#  TO  1 C- 1 41 A-2-AA  73-10-00  2JG  03522A 

I  4-3:  REMOVE  FUEL  RUMP  FILTER  ELEMENT.  CONTINUED.  6 

« 

#  C.  INSPECT  ELEMENT  *1*  FOR  CONTAMINATION  A  CLEAN  IF  NEEDED. 


**  '  "  *  . . . .  CAUTION  . . . 

INVESTIGATE  CAUSE  OF  METAL  OR  RUBBER  PARTICLES;  FUEL  SYSTEM 
MAY  BE  DAMAGED. 

t  I  ■  I  I  I  I  I  >  I  I  t  I  I  t  I  •  I  •  I  I  t  I  I  I  (  I  I  I  I  (  «  t  I  I  I  I  I  ■  I  I  I  t  •  I  4  I  I  I  I  I  I  I  •  I  »  I  ■  I  I 

END  OF  REMOVE  AND  INSPECT. 

*  ARE  YOU  GOING  TO  INSTALL  A  FILTER  ELEMENT  NOW? 


F  O  INPUT  [YES]  OR  [NO]:[  ];  [ENTER]. 


Figure  7-8.  Example  of  VAMIS  maintenance  procedure 
continuation  frame  (Track  2) . 


The  Track  2  procedures  formats  discussed  above  have  included 
both  text  and  illustrations,  appropriately  associated  through 
the  use  of  callouts.  For  some  kinds  of  maintenance  tasks,  it 
may  be  appropriate  to  provide  text  only,  with  no  illustrations. 
Alternatively,  there  may  be  cases  where  only  an  illustration  is 
needed,  without  text.  If  either  of  these  alternatives  is  used, 
the  level  of  detail  of  the  information  that  is  provided  may  need 
to  be  increased  to  assure  comprehension  by  the  technician. 
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7.5  TRACK  1  MAINTENANCE  PROCEDURES 


Experienced  and  highly  skilled  technicians  need  a  minimum  of 
procedural  guidance  for  the  conduct  of  routine  maintenance  tasks. 
In  VAMIS  it  is  planned  that  the  Summary  of  Procedures  (which  is 
the  last  frame  of  the  input  conditions  in  each  track)  will,  in 
effect,  comprise  the  Track  1  procedure  (see  Figure  7-5).  In  some 
circumstances,  however,  it  may  be  necessary  to  provide  additional 
procedural  guidance  for  Track  1,  such  as  for  a  particularly 
complex  calibration  or  alignment  task.  Rather  than  require  the 
Track  1  technician  to  use  Track  2  procedures,  the  following 
approach  is  recommended. 

Track  1  should  have  the  same  Summary  of  Procedures  IC  frame  as 
Tracks  2  and  3,  followed  by  separate  frames  of  procedural  data 
deemed  appropriate  for  a  Track  1  user.  These  frames  would 
include  any  applicable  warnings,  cautions,  specifications,  and 
diagrams  necessary  for  task  performance. 


SECTION  8.0 

GUIDELINES  FOR  TROUBLESHOOTING  PROCEDURE  FORMATS 

8.1  GENERAL  CONSIDERATIONS 

Procedures  for  troubleshooting  activities  are  also  prepared  at 
three  levels  of  detail,  or  tracks.  For  a  particular  system,  the 
levels  of  detail  needed  should  be  established  in  the  same  manner 
as  for  maintenance  procedures  (Section  7.0).  In  VAMIS,  trouble¬ 
shooting  encompasses  the  following  functions: 

•  Test  and  checkout 

•  Fault  isolation. 

Each  set  of  troubleshooting  procedures  will  include  the  in; at 
conditions  for  performing  the  selected  task,  test  and  checkout 
procedures,  and  fault  isolation  procedures.  Differences  in 
level  of  detail  for  the  three  tracks  will  apply  to  most  of  the 
data  for  a  task,  but  some  information  may  be  at  the  same  level 
of  detail  for  more  than  one  track.  Requirements  for  the  Logic 
Tree  Troubleshooting  Aids  (LTTAs) ,  which  are  the  baseline  format 
for  VAMIS  troubleshooting  procedures,  originate  in  specification 
MI L-M-38800A,  supplemented  by  the  formatting  and  preparation 
guidance  in  AFHRL  TR-79-49  (Ref.  2).  A  troubleshooting  task 
analysis  should  be  performed  prior  to  data  preparation.  The 
modified  task  analysis  methodology  (Ref.  7)  defined  during  this 
project  is  appropriate.  It  is  based  on  tailoring  the  maintenance 
task  identification  and  analysis  methods  and  guidance  of  AFHRL 
TP-79-50  (Ref.  5)  and  -80-21  (Ref.  6)  for  greater  compatibility 
with  a  computer-based,  three-track  presentation  system. 

Troubleshooting  data  are  procedural,  or  track,  information  and 
are  subject  to  the  level  5  viewing  distance  requirements.  This 


applies  to  text,  illustrations,  and  prompts,  and  should  be 
achieved  when  the  frame  first  appears  on  the  display  screen. 

The  frame  code  "FI"  is  used  on  all  frames  of  troubleshooting 
task  information. 

As  explained  in  Subsection  2.3,  LTTAs  have  two  parts.  The  first 
part,  termed  checkout,  is  aimed  at  determining  whether  a  fault 
exists  and,  if  so,  the  part  of  the  system  which  is  involved. 
Checkout  procedures  are  a  linear  series  of  checks  for  identifying 
a  fault.  Checkout  ends,  temporarily,  when  a  fault  is  identified. 
If,  for  a  given  system,  there  is  only  one  possible  cause  for  the 
identified  fault,  then  fault  isolation  has  been  accomplished 
simultaneously  with  fault  identification  and  the  next  activity 
will  be  fault  correction  (e.g.,  repair,  replacement,  adjustment). 
In  most  cases,  however,  the  cause  of  the  problem  will  require 
further  troubleshooting  to  isolate  the  fault  to  a  particular 
component.  When  the  fault  has  been  identified  using  a  system- 
level,  or  general,  checkout  procedure,  checkout  will  often 
continue  with  a  subsystem  or  assembly  checkout  before  beginning 
actual  fault  isolation. 

Fault  isolation  is  the  second  part  of  an  LTTA,  accomplished  with 
the  use  of  logic  trees.  Whereas  checkout  procedures  are  linear, 
logic  trees  are  "branching"  and  binary;  that  is,  there  are 
always  two,  but  not  more  than  two,  possible  next  steps  until  the 
problem  is  isolated.  The  quantitative  or  qualitative  results/ 
observations  of  one  step  determine  which  branch  to  follow  for  the 
next  step. 
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8.2  INPUT  CONDITIONS  FORMAT 

VAM1S  troubleshooting  procedures  will  use  the  same  input 
conditions  (IC)  format  described  for  maintenance  procedures  in 
Subsection  7.2.  There  are,  however,  some  differences  in  both 
content  and  application  in  troubleshooting. 

Separate  input  conditions  data  should  be  provided  for  a  checkout 
task  and  each  fault  isolation  task  which  may  result  from  the 
checkout.  Input  conditions  for  a  checkout  task  will  only  rarely 
apply  in  their  entirety  to  a  logic  tree  (LT)  task.  LTs  may  have 
some  additional  input  conditions,  and  should  always  include 
completion  of  the  checkout (s)  which  can  lead  to  that  logic  tree. 

Checkout  and  logic  tree  ICs  will  include  not  only  equipment  con¬ 
ditions,  but  may  also  include  test  setup  conditions  if  applicable. 
Special  test  setup  instructions  can  be  incorporated  either  in  the 
input  conditions  or  as  the  first  steps  in  the  checkout.  Standard 
test  setup  procedures  should  always  be  selectable  from  the 
options  list  for  the  IC  frame  which  identifies  the  need  for  it. 
Checkout  input  conditions  frames  will  include  the  "Summary  of 
Procedure"  frame  (see  Figure  7-4) ,  but  logic  tree  ICs  will  not. 

Jt  would  serve  no  useful  purpose  to  summarize  the  fault  isolation 
steps  encompassed  by  a  branching  logic  tree. 

It  the  equipment  system  is  using  fault  code  reporting  (see 
Subsection  8.6),  the  fault  codes  which  are  applicable  should 
be  listed  as  a  category  of  input  conditions  for  the  checkout 
or  fault  isolation  task,  as  applicable. 

8.3  TRACK  3  TROUBLESHOOTING  PROCEDURES 

Checkout  and  fault  isolation  procedures  for  the  least  skilled 
and  experienced  technician  are  prepared  at  the  same  detailed, 
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step-by-step  level  as  Track  3  maintenance  procedures.  Very 
specific  and  detailed  illustrations  are  always  provided,  fully 
integrated  with  the  procedural  text.  This  level  of  detail  in 
LTTAs,  and  the  resulting  format  characteristics,  is  termed 
enriched  LTTA.  The  two  parts  are  enriched  checkout  procedures 
and  enriched  logic  trees. 

8.3.1  Enriched  Checkout  Procedures 

Figure  8-1 (a)  illustrates  an  example  of  an  enriched  checkout 
procedure  frame  for  use  in  Track  3  troubleshooting.  The  approach 
and  format  are  the  same  as  Track  3  maintenance  procedure  formats 
(see  Subsection  7.3)  in  the  use  of  dual-level  subtask  statements 
followed  by  step-by-step  instructions  for  subtask  performance. 
Text  and  illustrations  are  completely  integrated  through  the 
use  of  callouts.  Each  subtask  should  start  on  a  new  frame. 

A  subtask  ends  with  a  question  which  must  be  answered  in  order 
to  proceed.  A  subtask  may  require  multiple  frames  and  should 
repeat  the  upper-level  subtask  statement  on  each  frame.  The 
question  is  not  displayed  until  the  last  frame  for  a  particular 
subtask. 

The  question  should  always  be  phrased  so  that  a  YES  corresponds 
to  an  acceptable  condition  and  a  NO  means  that  a  problem  exists. 
The  prompt  at  the  bottom  of  the  frame  uses  the  same  symbol, 

[?)  ,  as  marks  the  question,  and  the  technician  can  go  no 

further  until  the  question  is  answered. 

When  the  user  enters  the  observed  status  of  the  equipment  as  a 
result  of  performing  the  steps  and  answering  the  question,  the 
VAMIS  system  provides  feedback  in  the  prompt  area  to  aid  the 
technician  in  understanding  the  meaning  of  the  check  and  the 
implications  of  the  result.  Alternate  feedback  messages  are 
shown  in  Figures  8-l(b)  and  8-1  (c)  for  YES  and  NO  responses. 


Figure  8-1.  Track  3  troubleshooting — example  of  enriched 
checkout  frame. 
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respectively.  In  both  cases,  only  the  contents  of  the  prompt 
area  change  through  the  addition  of  a  feedback  message  for 
movement  of  the  prompt  marker.  For  the  YES  answer,  the  user 
is  told  what  component  was  determined  to  be  acceptable  and  what 
subtask  is  to  be  performed  next.  Since  system  logic  assumes  a 
YES  answer  is  normal,  the  FORWARD  function  key  can  be  used  to 
obtain  the  next  checkout  subuask. 

For  the  NO  answer,  the  user  is  told  what  part  of  the  system  may 
be  faulty  and  what  procedures  are  needed  to  continue  the  trouble¬ 
shooting  process,  in  this  case  a  logic  tree.  Input  of  a  NO 
instructs  the  system  to  depart  from  the  normal,  ordered  sequence, 
and  the  FORWARD  key  is  used  to  obtain  the  next  appropriate  frame. 

Feedback  messages  used  in  this  manner  not  only  keep  the  tech¬ 
nician  informed  of  the  meaning  of  the  checkout  actions,  but  also 
serve  to  provide  frame- to-frame  continuity.  Since  the  Track  3 
technician  is  seeing  only  very  small  "chunks”  of  the  overall 
procedure  on  any  one  frame,  the  context  and  flow  would  not  be 
apparent  without  such  feedback. 

8.3.2  Enriched  Logic  Tree 

Track  3  fault  isolation  procedures  are  presented  via  enriched 
logic  trees,  an  example  of  which  is  shown  in  Figure  8-2 (a). 

As  in  Track  3  checkout  procedures  (and  maintenance  procedures) , 
instructions  are  dual-level,  step-by-step,  with  illustrations. 
However,  LT  subtasks  are  enclosed  in  "boxes."  This  practice 
serves  the  dual  purpose  of  making  a  visual  distinction  between 
Track  3  LTs  and  checkouts,  as  well  as  improving  the  compatibility 
between  Track  3  and  Track  2  I.Ts . 

Also  as  in  Track  3  checkout  procedures,  feedback  messages  are 
used  to  provide  the  continuity  of  the  logic  tree  and  keep  the 
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#  TO  1 2PS-CH495-2-AA  29-21-03  3FI  ® 1 1 31 C 

t  LT  10-1:  HYDRAULIC  BLOWER  DOES  MOT  SPIN  WHEN  TURNED  ON.  4 

3.  "chTck  MOTOR  TO  BLOWER  SHAFT: 

«.  place  mechanics  stethescope  on  outlet  port  *5*  of 

MOTOR  *2*. 

6  .  SET  MOTOR  b"l TCH  *1*  TO  ON. 

C  LISTEN  FOR  A  COMBINATION  RUMBLING  AND  HHItllftG  NCISE  OF 
TURNING  MOTOR. 

A  !©  IS  THE  MOTOR  QUIET? 


KOTO*- 


cR  uuiy*  — 

JO. 

oo 


*  ©  INPUT  EITHER  [YES]  OR  [NO]:  [  ];  [ENTER]. 


INPUT  EITHER.  [YES]  OR  [NO]:  [YES];  [ENTER]. 
r\  qu]£t  MOTOR  MEANS  SPLINE  SHAFT  IS  OKAY:  [FORWARD] . 


INT":  EITHER  [YES]  OR  [NO]:  [NO];  [ENTER]. 

©NOISY  MOTOR  MEANS  SALINE  SHAFT  IS  BAD.  REPLACE  SPLINE 
SHAFT  WITH  JG  7-5.  FOR  PROCEDURE:  [FORWARD], 


'  •  \ 


Figure  8-2.  Track  3  troubleshooting — example  of  enriched 
logic  tree  frame. 
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technician  apprised  of  the  meaning  of  results  of  the  checks 
(Figures  8-2 (b)  and  8-2(c)).  Logic  tree  questions  are  also 
phrased  so  that  a  YES  response  corresponds  to  an  acceptable 
condition  and  a  NO  response  corresponds  to  an  unacceptable 
condition,  with  one  exception.  In  any  logic  tree,  the  last 
subtask  in  a  branch  should  isolate  two  different  faults,  one 
from  the  YES  response  and  the  other  from  the  NO.  A  properly 
constructed  logic  tree  branch  can  never  end  with  the  possibility 
of  a  "no  fault"  condition,  nor  should  it  lead  back  to  a  logic 
tree  step  through  which  the  technician  has  already  passed. 

One  of  the  binary  responses  may,  however,  result  in  going  to 
a  different  LT  for  further  fault  isolation. 

The  examples  in  Figures  8-3  and  8-4  illustrate  the  continuation 
of  the  enriched  LT  shown  in  Figure  8-2  (a)  with  implementation  of 
the  prompt/ feedback  in  Figure  8-2 (b) .  This  shows  the  division 
of  a  lengthier  step  into  a  two-frame  presentation. 

8.4  TRACK  2  TROUBLESHOOTING  FORMATS 

Checkout  procedures  and  logic  trees  for  Track  2  are  prepared  at 
the  middle  level  of  detail,  designated  in  AFHRL  TR-79-49  (Ref.  2) 
as  "minimally  enriched." 

8.4.1  Minimally  Enriched  Checkout  Procedures 

Figure  8-5  shows  an  example  of  a  Track  2  checkout  frame.  Logic 
is  the  same  as  in  Track  3  checkouts  in  that  questions  are  phrased 
so  that  a  NO  response  indicates  that  an  unacceptable,  or  fault, 
condition  exists.  This  example  uses  no  illustration  to  support 
the  text,  on  the  assumption  that  a  Track  2  technician  is  suffi¬ 
ciently  knowledgeable  of  the  equipment  to  know  where  the  controls 
and  indicators  are  located.  Other  tasks  may  make  use  of  simple 
illustrations  to  the  extent  needed.  Text  provides  the  basic 


statement  of  the  subtask  (the  upper  level  of  the  Track  3  dual 
level)  followed  by  a  brief  statement  of  what  to  do  and  what  to 
look  for.  Following  the  prompt  will  access  a  lower-level 
checkout  procedure  or  the  appropriate  logic  tree.  Feedback 
messages  are  not  used  as  a  means  of  providing  enrichment  and 
continuity  as  in  Track  3. 


#  TO  12PS-CH495-2-AA  29-21-03  3F1  01133B 

#  LT  10-1:  HYDRAULIC  BLOWER  DOES  NOT  SPIN  WHEN  TURNED  ON.  6 


MAKE  certain  electric  and  hydraulic  power  is  off.  a  powered 

FAN  THAT  BREAKS  FREE  WILL  CUT  OR  REMOVE  FINGERS. 


4.  CHECK  BLOWER  *3*  FREEDOM  TO  TURN  (CONTINUED) 

D.  REMOVE  TWO  SCREWS  *9*  FROM  ACCESS  PANEL  *7*. 

E.  OPEN  BLOWER  ACCESS  PANEL  *7*. 

F.  REACH  IN  AND  GRASP  FAN  BLADES  *3*  AND  TRY  TO  TURN 


#  [?)  INPUT  EITHER  f YES]  OR  [NO];  [  ];  [ENTER], 


Figure  8-4.  Track  3  troubleshooting — example  of  enriched 
logic  tree  frame,  continuation  frame 
presentation . 


Comparison  of  the  Track  2  checkout  procedure  with  that  of 
Track  3  (see  Figure  8-1)  clearly  shows  the  differences  in  level 
of  detail,  as  well  as  the  common  approach  except  with  regard  to 
enrichment.  If  the  Track  2  technician  decided  that  more  detailed 
guidance  was  needed,  the  choice  is  available  on  the  options  list 
(see  Figure  4-9).  It  should  be  noted,  however,  that  when  "more 
detail"  is  selected,  the  system  will  access  and  display  the  first 
frame  which  is  equivalent  for  the  two  tracks  (i.e.,  Figure  8-1). 
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to  i0P3-asq-99-2-aa  26-22-03 

2 F I  023E9B 

CHECKOUT  3-1:  B.  MANUAL  GROUND  SPEED  SLEW  CHECK. 

2 

¥ 

1 .  CHECK  "EMORY  LAMP : 

IF 

NO 

f 

-  SET  Power  SWITCH  to  slew  and  terrain  switch 

[ 

] 

TO  LAND. 

* 

(?)  DOES  MEMORY  LAMP  LIGHT  AND  REMAIN  LIT? . 

A 

# 

2.  CHECK  LEFT  SLEW: 

# 

-  HOLD  OR  SWITCH  TO  LEFT  FOR  25  TO  35  SECONDS, 

THEN  * 

SWITCH  TO  CENTER. 

* 

©DO  THESE  FOUR  ACTIONS  OCCUR  TOGETHER? 

* 

1.  MEMORY  LAMP  OFF  (NOT  LIGHTED) . 

B 

* 

2.  MEMORY  FLAG  OFF  (NOT  VISIBLE) . 

C 

3.  ANTENNA  ROTATES  CCW  SMOOTHLY  AND 

THEN  STOPS  SMOOTHLY . 

D 

A.  DRIFT  ANGLE  POINTER  FOLLOWS  ANTENNA . 

E 

b 

3.  CHECK  RIGHT  SLEW: 

$ 

-  HOLO  DR  SWITCH  TO  RIGHT  FOR  25  TO  35  SECONDS 

.  THEN 

b 

SWITCH  "0  CENTER. 

f 

©DO  THESE  FOUR  ACTIONS  OCCUR  TOGETHER? 

a 

1.  MEMORY  LAMP  OFF  (NOT  LIGHTED) . 

F 

* 

2.  MEMORY  FLAG  OFF  (NOT  VISIBLE) . 

G 

b 

3.  ANTENNA  ROTATES  CM  SMOOTHLY  AMD 

f- 

THEN  STOPS  SMOOTHLY . 

H 

A.  DRIFT  ANCLE  POINTER  FOLLOWS  ANTENNA . 

J 

* 

(?)  INPUT  KEY  CCDE  FOR  ANY  NO  ANSWER:  [  ];  (ENTER]. 

ALL  CHECKS  OKAY  ?  [FORWARD], 

V 

J 

Fiqure  8-5.  Track  2  troubleshooting — example  of  checkout 
f  rame . 


8.4.2  Minimally  Enriched  Logic  Trees 

Track  2  logic  trees  more  closely  resemble  the  traditional  graphic 
logic  tree  in  appearance,  as  shown  in  Figure  8-6.  Questions 
which  direct  the  test  to  be  performed  or  observations  to  be  made 
are  placed  in  boxes,  with  arrows  showing  the  path  to  be  followed 
depending  on  the  results  of  each  subtask. 
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P  LT  10-1:  HYDRAULIC  BLOWER  DOES  NOT  SPIN  WHEN  TURNED  ON.  2 

P 


1.  DOES  AUX  HYD  PRESS  GAGE 
RF  AD  2500  PS!  OR  MORF  ? 


WILL  TROOP  ALARM 
SWITCH  RING  ALARM? 


.YES’  A 
'  NO?  B 


A  HOT  HYDRAULIC  HOSE  CAN  CAUS^SERl  OUS  BURNS.  WEAR 

gloves  or  cover  hose  with  a  thick  cloth. 

2.  CAN  SURGE  BE  FELT  IN  HYDRAULIC  HOSE  WHEN  \ 

r i  owfr  switch  rs  turned  on  then  off? _ / 


P  3.  IS  MOTOR  QUIET  EVEN  WHEN  MOTOR  SWITCH  IS  ON?  \ 

#  YES  ~ / 

MAKE  CERTAIN  HYDRAULIC  POWER  IS  OFF. 

P  I  4.  CAN  BLOWER  BLADES  BE  TURNED  BY  HAND?  \ > 


NO?  D 


YES?  E 
NO?  F 


P  G>  INPUT  APPROPRIATE  KEY  CODES  FOR  ANSWERS:  [  ] ;[ ENTER] . 


Figure  8-6.  Track  2  troubleshooting--exam]'le  of  logic 
tree  frame. 


In  general,  a  YES  response  directs  the  techician  to  continue 
down  the  tree,  because  the  fault  has  not  been  isolated,  while  a 
NO  will  take  the  user  out  of  that  logic  tree.  Input  of  any  key 
code  will  result  in  display  of  a  feedback  message  which  identi¬ 
fies  the  component  determined  to  be  at  fault,  or  the  logic  tree 
to  be  used  for  continuing  troubleshooting.  This  use  of  feedback 
is  comparable  to  Track  3  logic  trees. 

8.5  TRACK  1  TROUBLESHOOTING  FORMATS 

Checkout  and  fault  isolation  procedures  for  the  most  skilled 
and  experienced  technician  provide  the  least  amount  of  detail. 

For  both  applications  the  format  more  closely  approximates  a 
simple  checklist. 

3.5.1  Track  1  Checkout  Procedure 

The  checkout  procedure  for  Track  1  lists  the  checks  to  be  made, 
in  the  correct  sequence,  just  as  in  the  more  detailed  tracks.  As 
snown  in  Figure  8-7,  however,  no  guidance  is  provided  regarding 
the  location  of  the  component  or  how  the  test/observation  is  to 
be  accomplished.  The  only  assistance  is  to  show,  for  each  check, 
what  the  correct  status  or  indication  should  be.  For  any  observed 
o!l -normal  indication,  the  technician  can  access  the  appropriate 
lower -level  checkout  frame  or  logic  checklist  with  input  of  a  key 
code.  No  feedback  is  provided  for  identifying  faulty  items  or 
disclosing  the  procedure  that  will  be  accessed. 


I  TO  5N 1  -  3- 8- 2- AA  34-60-00  1F1  01842B 

¥  CHECKOUT  3-1:  A.  POWER  TURN-ON  AND  DISTRIBUTION.  2 

t 

#  CHECK  COMPONENT  NORMAL  STATUS/ 

#  [  ]  INDICATION 

¥  1  AIR  NAVI G  MULTIPLE  INDICATOR  FLAG .  VISIBLE 

#  2  OFF/MAN/AUTO  SWITCH .  MAN 

¥  3  AIR  NAVIG  MULTIPLE  INDICATOR  FLAG .  NOT  VISIBLE 

¥  4  NAVIG  COMPUTER  BLOWER .  OPERATING 

¥  5  TEST  HARNESS,  115V  AC  SWITCH .  OFF 

# 

*  6  CONTROL  INDICATOR  OFF  INDICATOR .  LIGHTED 

¥  7  TEST  HARNESS,  115V  AC  SWITCH .  ON 

¥  8  TEST  HARNESS.  TEST  POINT  B 1  2  ( HOT ) .  26  VAC 

¥  3  TEST  HARNESS,  TEST  POINT  E6  ( RETURN ) .  <.6  VAC 

¥  10  TEST  HARNESS,  HEADING  TRACK  READOUT 

BETWEEN  TEST  POINTS  D6  AND  D7 .  PRECISE  NULL 


*  2  FOR  FI  DATA:  INPUT  FAKED  CHECK  NUMBER  [  ];  [ENTER], 

Q  FOP.  CONTINUATION  OF  BENCH  CHECK:  [FORWARD], 


Figure  8-7.  Track  1  troubleshooting — example  of  bench 
checkout  frame. 


8.5.2  Track  1  Logic  Checklist 

Fault  isolation  procedures  for  Track  1  continue  the  checklist 
philosophy  of  the  checkout  procedure.  Figure  8-8  illustrates  the 
reduction  of  the  Track  2  logic  tree  (Figure  8-7)  into  checklist 
format.  This  logic  checklist  contains  only  the  bare  essentials 
of  symptom  identification  and  status  information,  but  is  based 
on  the  same  sequence  of  checks  as  in  the  logic  tree.  Branching 
sequences  are  reflected  by  indentured  steps. 


A  feature  of  the  logic  checklist  not  found  in  the  more  detailed 
logic  trees  is  pre-identification  of  faults  resulting  from  the 
associated  f  nptom.  While  this  characteristic  is  somewhat 
similar  to  the  s^miptom-cause  tables  in  some  conventional  TOs 
and  the  troublesnooting  data  charts  described  in  MIL-M-38800A , 
the  sequencing  of  symptom  checks  according  to  the  logic  tree 
places  this  format  in  the  LTTA  fami] 


8.6  FAULT  CODE  REPORTING 


VAMIS  formats  do  not,  at  present,  incorporate  the  use  of  fault 
code  reporting  as  provided  by  specification  MIL-M-83495.  These 
fault  codes  are  based  partly  on  the  numerical  MIDAS  code  (see 
paragraph  3.8.3)  to  localize  and  report  a  fault.  The  fault  code 
(e.g.,  "2920/A1B1Z" )  can  then  be  used  to  identify  the  point  of 
entry  into  a  checkout  procedure  or  logic  tree  for  further  fault 
isolation.  The  greatest  advantage  to  fault  code  reporting  such 
as  this  is  when  troubleshooting  is  partially  accomplished  by  one 
organization  but  must  be  completed  by  a  different  organization. 
Since  the  fault  code  effectively  identifies  the  point  at  which 
fault  identification  ended  (in  the  first  organization)  it  can  be 
used  as  an  index  of  where  to  start  (in  the  second  organization) , 
eliminating  the  need  to  repeat  the  same  troubleshooting  steps. 
When  this  method  of  fault  reporting  is  to  be  used,  provisions 
should  be  made  for  inclusion  of  fault  codes  in  the  data  for  each 
organizational  level  affected.  This  may  entail  incorporating 
the  appropriate  fault  code  at  the  end  of  checkout  steps  and 
providing  fault  code  index  tables  as  a  means  of  entering  a 
checkout  procedure  or  selecting  an  appropriate  logic  tree. 


SECTION  9.0 

INSTRUCTIONS  FOR  USING  VAMIS 


9.1  INTRODUCTION 

A  VAMIS -type  system,  like  any  other  system  or  major  equipment 
item  in  the  USAF  inventory,  will  require  instructions  for 
operation  and  maintenance.  Presumably  such  instructions  will  be 
formalized  as  an  Air  Force  TO,  probably  in  the  General  Technical 
Order  category,  and  be  subject  to  all  applicable  TO  requirements. 
VAMIS  instructions  and  procedures  will,  however,  be  unique  in 
several  respects: 

•  The  system  that  is  the  subject  of  the  instructions  will  also 
be  the  means  by  which  operating  procedures  and  related 
information  are  presented  to  the  user. 

•  The  system  could,  ironically,  be  one  of  the  few  equipment 
systems  for  which  maintenance  instructions  will  be  required 
both  as  paper-based  TOs  and  automated  procedures.  Unless 
redundant  systems  are  available  in  the  applicable  mainte¬ 
nance  area,  paper-based  procedures  will  be  needed  for 
power-off  maintenance  and  for  fault  isolation  and  repair 
when  VAMTS  is  malfunctioning. 

The  materials  in  this  section  deal  only  with  the  consolidated 
operating  procedures  and  guidance  for  the  baseline  system. 
Explanation  of  the  use  of  frame  prompts,  feedback,  and  advisory 
messages  is  provided  in  Section  3.0  and  will  be  incorporated,  as 
appropriate,  in  the  user  instructions.  VAMIS  maintenance,  fault 
isolation,  and  repair  procedures  are  dependent  on  equipment 
configuration  and  characteristics  that  are  beyond  the  scope  of 
this  project. 
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9.2  USER  ORIENTATION 


Instructions  for  use  of  the  system,  i.e.,  the  users'  guide,  must 
satisfy  the  needs  of  a  variety  of  user  types.  On  the  one  hand, 
it  must  enable  an  individual  with  no  prior  knowledge  of  or 
experience  with  this  or  any  similar  system  to  become  sufficiently 
familiar  with  its  capabilities  and  characteristics  to  be  able 
to  use  it  in  lieu  of  a  paper-based  TO  for  the  performance  of 
maintenance  on  other  equipment.  At  the  other  extreme,  the  users' 
guide  must  provide  assistance  with  specific  problems  and  answers 
to  specific  questions,  which  even  the  most  experienced  user  may 
have,  without  going  through  extensive  search  routines. 

Since  familiarity  with  VAMIS  will,  at  least  initially,  be 
independent  of  skill  levels  of  the  using  technicians,  user  guide 
information  should  be  prepared  for  the  worst  case.  Operating 
procedures  and  explanations  should  be  prepared  at  a  level  of 
detail  equivalent  to  Track  3.  Maintenance  procedures  for  the 
system,  when  prepared,  should  be  at  all  three  levels  of  detail, 
following  the  same  criteria  as  for  other  TO  maintenance 
procedures  to  be  presented  via  VAMIS. 

9.3  ACCESSING  THE  USERS'  GUIDE 

The  need  for  access  to  the  users'  guide  may,  as  is  discussed  in 
Section  4.0,  be  one  of  the  first  requirements  when  a  potential 
user  wants  to  sign-on  the  system.  The  system  title  frame,  which 
was  depicted  in  Figure  4-2,  provides  a  means  for  any  user  (and 
especially  "unauthorized"  users)  to  obtain  the  users'  guide.  In 
uddition,  although  not  shown  in  the  access  paths  illustrated  in 
Figure  4-1,  if  the  users'  guide  becomes  a  Technical  Order  in  its 
own  right,  it  would  be  listed  in  the  master  TOC,  or  list  of  TOs . 
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and  could  be  accessed  from  that  listing  (see  Figure  4-3).  The 
third  method  of  accessing  the  users’  guide,  and  the  one  which 
is  most  important  to  qualified  users,  is  from  any  options  list 
in  any  of  the  TOs  that  are  part  of  the  data  base.  An  example  of 
an  options  list,  with  the  users’  guide  as  one  of  the  available 
options,  was  presented  in  Figure  4-9. 

id  ;nre  9-1  illustrates  the  relationship  between  the  contents  of 
the  users'  guide  for  V AM T S  and  the  other  materials  in  the  data 
base.  Note  that  the  system  title  frame  and  the  master  TOC  are 
part  of  the  users'  guide,  since  they  provide  user  guidance  for 
accessing  the  system  and  its  contents.  Accordingly,  these 
frames  carry  "AA"  frame  codes.  Options  lists  that  are  related 
to  specific  system  TOs,  on  the  other  hand,  are  not  part  of  the 
users'  guide  even  though  they  provide  guidance  to  the  user.  The 
system  title  frame  and  the  master  TOC  are  the  only  users'  guide 
frames  that  the  individual  technician  will  see  on  a  routine 
basis. 

9.4  USERS '  GUIDE  CONTENTS 

As  with  most  other  TOs  in  the  VAMIS  data  base,  the  users'  guide 
will  contain  both  procedural  and  non-procedural  information. 
However,  since  the  users'  guide  forms  a  part  of  the  pool  data 
tor  oLhor  TOs  in  the  data  base,  all  materials  in  the  guide 
should  be:-  considered  as  pool.  This  will  allow  the  RETURN  key  on 
the  control  unit  to  have  a  consistent  function. 

The  users'  guide  will  comprise  a  variety  of  front  matter, 
procedural  instructions,  and  reference  materials.  How  much  of 
these  materials  ai e  presented  to  a  particular  user,  and  in  what 
sequence,  will  be  partly  dependent  on  the  reason  for  accessing 
the  guide.  The  experienced  user  should  be  able  to  obtain  needed 
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information  by  the  most  direct  route  feasible  and  then  return 
directly  to  the  origin  of  the  request.  The  new,  or  inexperienced 
user,  should  first  be  presented  with  the  data  which  are  deemed 
most  important  to  the  learning  process,  and  gradually  work  up  to 
a  complete  understanding  of  the  system.  Figure  9-1  illustrates 
the  basic  interfaces  of  these  two  user  types  with  respect  to  the 
data  in  the  users'  guide.  Note  that  experienced  users  have 
access  to  the  same  data  whether  they  enter  the  users'  guide  via 
an  options  list  or  from  the  system  title  frame.  In  addition,  if 
desired,  the  experienced  user  can  follow  the  same  paths  as  are 
planned  for  an  inexperienced  user. 

The  types  of  information  included  in  the  users'  guide  are 
identified  in  Figure  9-1.  Users  who  follow  the  "hardwired" 
sequence  (by  using  the  FORWARD  key)  will  be  introduced  to  each 
topic  at  a  general  level,  and  then  be  presented  with  details  of 
that  topic,  before  going  on  to  the  next  topic.  Users  who  are 
somewhat  knowledgeable  of  the  system,  or  who  are  not  interested 
in  details  of  nil  topics,  can  move  sequentially  from  topic  to 
topic  by  using  the  NEXT  SEQUENCE  key.  Details  for  specific 
topics  can  then  be  reviewed  with  the  FORWARD  key.  Experienced 
users  who  want  specific  information  will  normally  access  that 
information  from  the  users'  guide  options  list  or  index. 


it  should  be  noted  that  even  though  many  users  who  have  accessed 
the  users'  guide  via  the  system  title  frame  will  have  little  or 
no  knowledge  of  how  to  interact  with  it,  no  special  restrictions 
arc  placed  on  control  unit  function  availability  within  the 
users'  guide.  Prompting  and  more  detailed  instructions  will  be 
depended  upon  to  lead  the  technician  smoothly  through  the 
materials,  and  system  design  will  prevent  him/her  from  getting 
totally  lost  or  getting  outside  the  users'  guide  into  some  other 
part  of  the  data  base. 


9-5 


9.5  INTRODUCTORY  MATERIALS 


The  initial  frames  of  the  users'  guide  are  intended  primarily  for 
users  who  are  new  to  VAMIS,  having  accessed  the  users'  guide  from 
the  system  title  frame.  The  users'  guide  preface,  an  example  of 
which  is  illustrated  in  Figure  9-2,  lets  the  user  know  what  part 
of  the  data  base  has  been  accessed,  and  what  its  purpose  is.  In 
addition,  basic  guidance  about  how  to  interact  with  the  system 
controls  and  display  is  presented  to  reduce  the  likelihood  of 
inexperienced  users  getting  lost.  The  preface  also  reminds  more 
experienced  users  that  they  can  follow  a  more  flexible  path  to 
obtain  specific  data  if  they  prefer. 
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Figure  9-2.  Example  of  VAMIS  users'  guide  preface  frame 


The  next  frame  of  the  users'  guide,  in  the  normal  sequence,  is 
the  introduction,  an  example  of  which  is  presented  in  Figure  9-3. 
The  introduction  has  two  purposes: 

1.  Provide  an  overview  of  the  contents  of  the  users'  guide  so 
that  users  can  anticipate  the  materials  to  be  presented. 

2.  Provide  guidance  to  new  users  on  how  best  to  utilize  the 
users'  guide  for  becoming  acquainted  with  the  system. 
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Figure  9-3 


Example  of  VAMIS  users’  guide  introduction  frame 


The  content  description  is  not  unlike  the  users'  guide  options 
list,  to  be  discussed  later,  or  a  typical  table  of  contents.  The 
principal  difference  is  that  no  provisions  are  made  for  selecting 
a  topic  or  subtopic,  bypassing  information  which  should  be  pre¬ 
sented  first.  As  mentioned  above,  and  discussed  in  more  detail 
in  paragraph  9.7.2,  the  users'  guide  options  list  is  available 
for  that  purpose  for  users  who  are  knowledgeable  enough  to  make 
use  of  it. 

9.6  USERS'  GUIDE  DESCRIPTIVE  DATA 

The  desc:  ^ptive  data  in  the  users'  guide  encompass: 

•  The  system  configuration  and  concept 

•  Codes  and  conventions 

•  Control  unit  functions 

•  User  modes  and  interactions 

•  Data  types  and  formats  in  the  data  base. 

Each  topic  is  presented  at  two  levels,  and  begins  with  a  frame 
which  discusses  the  subject  in  general  and  identifies  the 
principal  subtopics.  The  general  discussion  should  be  complete 
in  one  frame,  but  is  supported  by  additional  frames  of  detailed 
descriptions,  to  the  level  needed  to  enable  the  user  to  gain  a 
full  understanding  of  that  aspect  of  the  system  as  it  might 
pertain  to  his  or  her  job.  The  prompt  on  each  "general"  frame 
will  inform  the  user  of  his/her  choices — to  explore  the  subject 
in  greater  detail  (by  pressing  FORWARD)  or  to  go  on  to  the  next 
topic  (by  pressing  NEXT  SEQUENCE) .  If  the  individual  elects  the 
detailed  discussion,  progress  through  that  part  of  the  users' 
guide  is  primarily  with  the  FORWARD  key.  At  the  last  frame  of 
the  detailed  discussion  of  each  topic,  the  user  is  prompted  that 
the  sequence  can  be  reviewed  again  (with  REPEAT  SEQUENCE)  or 


the  next  topic  can  be  obtained  (with  FORWARD).  In  some  topics, 
because  of  their  scope,  the  nodes  which  cue  the  prompts  for 
REPEAT  SEQUENCE  are  at  the  subtopic  level  (e.g.,  control  unit 
functions) . 

In  order  to  eliminate  cross-referencing  between  topics  and 
subtopics,  and  at  the  same  time  implement  both  the  bilevel  pre¬ 
sentation  of  data  and  the  sequential  order  of  topic  presentation, 
the  users'  guide  will  incorporate  a  fair  amount  of  redundancy. 

For  example,  VAMIS  detailed  description  frames  covering  the 
control  unit  may  include  some  of  the  same  information  as  is 
included  in  the  control  unit  functions  general  frame. 

9.6.1  VAMIS  Descriptions 

Figure  9-4  presents  an  example  of  a  general  description  frame, 
with  VAMIS  as  the  baseline  system  of  reference.  At  this  level, 
the  system  is  described  only  in  general  terms,  stating  what  the 
system  does,  the  major  equipment  items  that  comprise  it,  and 
generally  how  they  interact.  The  remainder  of  the  frame  is  used 
to  prompt  the  user  on  what  his/her  primary  action  choices  consist 

of  and  what  should  be  done  to  obtain  the  available  information. 

Figure  9-5  illustrates  an  example  of  a  frame  of  detailed 
description  of  the  system  comprising  the  hardwired  sequences, 
which  would  be  accessed  from  the  general  description  frame  by 
using  the  FORWARD  key.  Further  use  of  the  FORWARD  key  will 
continue  the  presentation  of  detailed  description  data  or,  if  it 
is  the  last  frame,  will  go  on  to  the  next  topic.  The  user  is 

also  reminded  that  since  this  is  the  last  frame  of  the  subtopic, 

it  can  be  reviewed  by  pressing  REPEAT  SEQUENCE. 
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Fiqure  9-5.  Example  of  VAMIS  users'  guide  detailed 
description  frame. 


9.6.2  VAMIS  Codes  and  Conventions 

In  order  for  VAMIS  users  to  begin  to  understand  how  to  interact 
with  the  system,  it  is  necessary  for  them  to  become  familiar 
with  the  codes  and  conventions  that  are  used  on  data  frames- and 
in  prompts.  With  this  information,  the  subsequent  information 
in  the  users'  guide  will  be  easier  to  present  and  easier  to  use 
An  example  of  the  general  codes  and  conventions  frame  is  shown 
in  Fiqure  9-6,  comprising  an  identification  of  the  various 
codes,  symbols,  and  other  graphic  and  text  conventions  that  ai  ■ 
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9.6.3  VAMIS  Control  Unit  Functions 


This  topic  in  the  usefs'  guide  is  probably  the  most  important 
to  the  user  as  far  as  knowing  how  to  interface  with  the  system 
is  concerned.  With  the  knowledge  of  what  to  expect  from  each 
key  on  the  control  unit  under  different  conditions,  and  the  pre 
ceding  codes  and  conventions  data,  the  technician  can  interact 
effectively  (if  not  proficiently)  with  the  system.  Figure  9-8 
provides  an  example  of  the  general  control  unit  functions 
explanation;  Figure  9-9  shows  an  example  of  a  detailed  control 
unit  functions  description  frame. 
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Fiaurc  9-9.  Exanple  of  VAMIS  users'  guide  detailed  control 
unit  functions  frame. 


Whc-n  users  are  reviewing  explanations  of  control  unit  functions, 
there  is  a  risk  that  they  will  want  to  try  it  to  see  if  the 
control  actually  does  what  is  described.  For  some  controls  this 
will  have  no  significant  effect  (e.g.,  using  input  group  keys 
while  on  a  non-selection  frame;  the  system  will  display  an  error 
message) .  For  others,  the  display  may  change  in  some  respects 
but  should  not  cause  a  problem  (e.g.,  the  screen  controls). 
However,  some  controls  could,  if  actuated  at  the  wrong  time, 


especially  by  an  unknowledgeable  user,  result  in  the  user 
getting  temporarily  lost  in  the  users'  guide.  In  order  to 
reduce  this  possibility,  several  precautions  are  needed.  The 
initial  detailed  control  unit  functions  frame  will  contain  a 
caution  notice  advising  the  user  of  the  potential  problems  that 
could  result  from  indiscriminate  actuation  of  the  keys.  Each 
individual  frame  will  either  inform  the  user  that  the  control (s) 
being  discussed  can  or  should  not  be  activated  (see  Figure  9-9), 
as  applicable. 

9.6.4  VAMIS  User  Modes  and  Interactions 

The  general  frame  on  this  topic  will  explain,  as  illustrated  in 
Figure  9-10,  the  three  modes  of  using  the  system.  This  will  be 
followed  by  more  detailed  descriptions  of  each  user  mode,  and 
the  specific  capabilities  and  limitations  that  exist  in  each 
mode.  The  remainder  of  this  topic  will  be  a  series  of  guided 
practical  exercises  covering  interactions  in  each  mode  of  use. 

For  this  purpose,  a  special  "closed"  data  base  will  be  created 
so  that  the  user  can  exercise  each  mode  in  a  variety  of  ways 
without  risk  of  getting  lost. 

To  guide  the  exercises,  an  instruction  frame  explains  what  to 
do,  as  shown  in  the  example  in  Figure  9-11.  This  example  is 
based  on  the  assumption  that  the  user  will  already  have  received 
instruction  on  the  basic  control  unit  functions  and  the  discussion 
of  the  purpose  of  the  user  request  mode  and  how  to  use  it.  This 
frame  guides  the  user  through  each  step  of  the  exercise,  with 
feedback  on  errors. 
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Figure  9-11.  Example  of  VAMIS  users'  guide  user  modes  and 
interactions  instruction  frame. 


9.6.5  VAMIS  Data  Types  and  Formats 


This  topic  is  the  last  of  the  descriptive  data  in  the  users' 
guide.  Those  who  have  progressed  through  the  topics  preceding 
it  in  the  ordered  sequence  should  be  familiar  with  the  system 
and  how  to  interact  with  it.  This  topic  will  cover  the  types  of 
data  that  make  up  the  individual  TOs  in  the  data  base,  how  the 
data  are  formatted  and  why,  and  the  ways  the  technician  can  use 
the  various  data  types  and  formats  for  accomplishing  maintenance. 

Figure  9-13  illustrates  an  example  of  the  general  overview 
frame  for  this  topic.  The  scope  outlined  in  the  example  is,  as 
mentioned  previously,  based  on  the  data  types  and  formats  that 
form  the  baseline  for  the  VAMIS  definition  project.  If  other 
data  types  and  formats  are  eventually  included,  appropriate 
changes  will  be  necessary. 

Figure  9-14  shows  an  example  of  a  frame  of  specific  information 
included  in  the  data  types  portion  of  this  topic,  describing 
levels  of  detail  associated  with  procedural  data.  Subsequent 
frames  on  this  subtopic  should  illustrate  the  differences 
between  Tracks  1,  2,  and  3  levels  of  detail. 

Detailed  descriptions  and  explanations  of  formats  used  in  the 
system,  and  how  they  are  intended  to  support  the  conduct  of 
maintenance,  should  comprise  the  remainder  of  this  topic  in  the 
users'  guide.  This  discussion  should  be  in  some  detail,  encom¬ 
passing  most  of  the  format  type  examples  included  in  the  preceding 
sections  of  this  report.  The  method  of  presentation  is  similar 
to  the  approach  used  for  the  user  modes  and  interactions  guidance 
discussed  in  paragraph  9.6.4.  For  each  format  type,  one  or  more 
discussion  frames  will  describe  the  features  and  characteristics, 
with  illustrations  included  as  appropriate.  Discussion  frames 


will  be  supported  by  example  frames,  some  of  which  will  be  the 
same  as  those  supporting  the  user  modes  and  interactions  practice 
trials  (see  Figure  9-12) . 
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Figure  9-14.  Example  of  VAMIS  users’  guide  detailed  data 
types  and  formats  frame  (level  of  detail). 


9.7  OTHER  USERS'  GUIDE  DATA 

The  remaining  information  in  the  users'  guide  for  VAMIS  is, 
with  one  exception,  unique  to  the  users'  guide  only  in  terms  of 
content.  It  is  assumed  that  users  who  reach  this  point  in  the 
data  base  have  either  proceeded  through  the  ordered  sequence  of 
explanations  shown  in  Figure  9-1,  and  described  above,  or  have 
entered  the  users'  guide  via  a  specific  TO  options  list.  In 
both  cases,  the  user  should  have  at  least  a  basic  understanding 
of  how  to  interact  with  the  system. 


\-av-; 


Cj 


-*V.v 

$5 

»•  u 


9-22 


9.7.1  Users'  Guide  Glossary  and  Index 

The  glossary  and  index  sections  of  the  users'  guide  are  identical 
in  format  and  scope  to  the  glossary  and  index  portions  of  the 
specific  TOs  included  in  the  VAMIS  data  base.  These  are  dis¬ 
cussed  in  Subsections  5.6  and  5.7  for  glossaries  and  indexes, 
respectively.  As  with  specific  TOs,  the  contents  of  the  users' 
guide  glossary  and  index  sections  are  based  on  the  contents  of 
the  "reference  TO,"  which  in  this  case  is  the  users’  guide. 

Access  to  specific  information  in  either  the  glossary  or  index 
is  obtained  only  through  the  respective  introduction  frames. 

9.7.2  Users 1  Guide  Options  List 

The  options  list  for  the  users'  guide  is  identical  in  concept  to 
any  other  options  list,  an  example  of  which  is  shown  in  Figure  4-9 
in  Section  4.0.  Only  three  differences  are  noteworthy: 

•  The  users'  guide  options  list  is  singular,  i.e.,  there  is 
only  one  usable  options  list  for  the  entire  users'  guide; 
whereas,  specific  TO  options  lists  are  unique  to  the 
individual  procedural  or  pool  data  frame  for  which  they 
were  prepared. 

•  The  users'  guide  options  list  is  multiframe  to  permit 
greater  inclusion  of  detail;  whereas,  specific  TO  options 
lists  are  single  frame. 

•  The  users'  guide  options  list  will  include  a  specific 
prompt,  as  a  concession  to  an  inexperienced  VAMIS  user 
who  may  access  it  inadvertently  or  out  of  curiosity,  for 
actuation  of  the  RETURN  key  to  get  back  to  the  reference 
f  rime . 

The  content  of  the  users'  guide  options  list  should  be  at  a 
level  of  detail  that  will  allow  the  user  to  access  subtopics  of 
the  guide.  To  access  specific  subjects,  the  use  of  the  index 


will  be  requ i r ed . 


9.7.3  Users*  Guide  Summary 

The  summary  frame,  an  example  of  which  is  presented  in  Figure  9-15 
is  unique  to  the  users'  guide  in  the  VAMIS  data  base.  Since  the 
guide  is  intended,  at  least  for  new  users,  to  be  reviewed  in  an 
ordered  sequence,  the  summary  frame  lets  the  user  know  that  he/she 
has  reached  the  end  of  the  "manual"  and  what  topics  have  been 
covered,  and  it  is  an  easy  method  for  getting  back  to  any  of  the 
topics  for  further  review.  In  a  sense  it  is  a  table  of  contents 
placed  at  the  end  of  the  "document."  It  is  expected  that  many 
users  will,  on  their  first  exposure  to  the  users'  guide,  not 
spend  the  time  to  go  through  each  topic  at  the  detailed  level. 

The  summary  frame  will  promote  going  back  to  specific  topics  for 


more  detailed  information. 
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F iaure  9-] 5.  Example  of  VAMIS  users’  guide  summary  frame 
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